Jim Nasby <jim.na...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers