Re: Bug in walsender when calling out to do_pg_stop_backup (and others?) - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Bug in walsender when calling out to do_pg_stop_backup (and others?)
Date
Msg-id 201110271743.p9RHhuU17462@momjian.us
Whole thread Raw
In response to Re: Bug in walsender when calling out to do_pg_stop_backup (and others?)  (Greg Jaskiewicz <gj@pointblue.com.pl>)
List pgsql-hackers
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
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 signal handler, etc.

A C comment might help there.

-- Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot Standby startup with overflowed snapshots
Next
From: "Kevin Grittner"
Date:
Subject: Re: out-of-order caution