Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> I do think it's interesting that the data appeared to be completely fine
> until I actually ran whatever the first assembly instruction of the for
> loop is, so presumably it was fine after the sigsetjmp() call (which I'm
> assuming is what causes all the fuss to begin with...) From my
> understanding of what volatile does, I can understand why it might be
> necessary for something in the CATCH block to need it, but not in the TRY.
While I was at Salesforce we saw some *extremely* odd behaviors in PG_TRY
blocks that we eventually tracked down to the compiler effectively trying
to store two different local variables in the same register. I don't
recall all the details anymore, but it had something to do with register
spills to stack locations and subsequent reloads happening at unfortunate
places with respect to the sigsetjmp call. I figured it was a bug in the
specific compiler we were using, because nobody in the PG community was
reporting any problems with identical code. Anyway, "volatile" was an
effective way of suppressing the issue. I wonder whether you're seeing
something similar. You'd have to grovel through the assembly code for
the function with and without "volatile" to be sure.
regards, tom lane