Peter Eisentraut <pete...@gmx.net> writes:
> On ons, 2010-02-17 at 11:05 -0500, Tom Lane wrote:
>> Since oldcontext is only set in the one place, it really shouldn't
>> require "volatile" decoration, but maybe it does.
> It is my understanding that local automatic variables may be clobbered
> by [sig]longjmp unless they are marked volatile. The PG_CATCH branch is
> reached by means of a [sig]longjmp. So that would mean that any
> variable that you want to use both before the TRY and inside the CATCH
> has to be volatile.
If the rule were quite that strict then we'd need many more "volatile"
markers than we have. I believe the actual implementation issue is that
longjmp restores the register contents to what they were at the time of
the setjmp call, and thus a variable allocated in a register would get
restored to the value it had at entry to PG_TRY whereas a variable
allocated on the stack would still have an up-to-date value. Now the
picture isn't quite that simple since a sufficiently smart compiler
might move the variable's value around within the routine. But the
behavior gcc appears to exhibit is that it won't warn about variables
that are only assigned once before the PG_TRY is entered, and that seems
reasonable to me since such a variable ought to have the correct value
either way.
It might be interesting to modify these bits of code so that the
oldcontext variables are assigned only at declaration:
MemoryContext oldcontext = CurrentMemoryContext;
...
PG_TRY();
and see if that makes the issue go away.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
