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:

Reply via email to