Re: Bug in walsender when calling out to do_pg_stop_backup (and others?)
От | Bruce Momjian |
---|---|
Тема | Re: Bug in walsender when calling out to do_pg_stop_backup (and others?) |
Дата | |
Msg-id | 201110271743.p9RHhuU17462@momjian.us обсуждение исходный текст |
Ответ на | Re: Bug in walsender when calling out to do_pg_stop_backup (and others?) (Greg Jaskiewicz <gj@pointblue.com.pl>) |
Список | 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 по дате отправления: