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
markas ClientConnectionLostPending as volatile just to be consistent. Not sure whether that's a good idea, or not. It
mightprevent a mistake should we ever add code to detect lost connections asynchronously (i.e., from somewhere else
thanpq_flush). And the cost is probably negligible, because CHECK_FOR_INTERRUPTS tests for InterruptPending before
callingProcessInterrupts(), so we only pay the cost of volatile if there's actually an interrupt pending. But I still
thinkit's better to add qualifies such a volatile only when really necessary. A comment about why it *isn't* volatile
isprobably 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
signalhandler, 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
haveyears of experience as developer and doing (relatively) well thanks to PostgreSQL - makes sense to contribute
somethingback.