On 19 Oct 2011, at 18:28, Florian Pflug wrote: > All the other flags which indicate cancellation reasons are set from signal > handers, I believe. We could of course mark as ClientConnectionLostPending as > volatile just to be consistent. Not sure whether that's a good idea, or not. > It might prevent a mistake should we ever add code to detect lost connections > asynchronously (i.e., from somewhere else than pq_flush). And the cost is > probably negligible, because CHECK_FOR_INTERRUPTS tests for InterruptPending > before calling ProcessInterrupts(), so we only pay the cost of volatile if > there's actually an interrupt pending. But I still think it's better to add > qualifies such a volatile only when really necessary. A comment about why it > *isn't* volatile is probably in order, though, so I'll add that in the next > version of the patch. > Makes sense.
I had to ask, because it sticks out. And indeed there is a possibility that someone will one day will try to use from signal handler, etc. > best regards, > Florian Pflug > > PS: Thanks for the review. It's very much appreciated! No problem, Got inspired by the talk I attended here at the pgconf.eu. Seems like a good idea to do these things, I have years of experience as developer and doing (relatively) well thanks to PostgreSQL - makes sense to contribute something back. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
