Greg Jaskiewicz wrote: > > 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.
A C comment might help there. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
