| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Greg Jaskiewicz <gj(at)pointblue(dot)com(dot)pl> |
| Cc: | Florian Pflug <fgp(at)phlo(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Bug in walsender when calling out to do_pg_stop_backup (and others?) |
| Date: | 2011-10-27 17:43:56 |
| Message-ID: | 201110271743.p9RHhuU17462@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2011-10-27 17:51:50 | Re: out-of-order caution |
| Previous Message | Simon Riggs | 2011-10-27 17:27:51 | Re: Hot Standby startup with overflowed snapshots |