Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-12-09 Thread Heikki Linnakangas
On 03.12.2011 18:37, Heikki Linnakangas wrote: One small change I'd like to make is to treat the loss of connection more as a new top-level event, rather than as a new reason for query cancellation. A lost connection is more like receiving SIGTERM, really. Please take a look at the attached

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-12-03 Thread Heikki Linnakangas
On 19.10.2011 19:41, 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

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-27 Thread Bruce Momjian
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

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-19 Thread Florian Pflug
On Oct19, 2011, at 17:47 , Greg Jaskiewicz wrote: On 15 Oct 2011, at 11:31, Florian Pflug wrote: Ok, here's a first cut. So I looked at the patch, and first thing that pops out, is lack of the volatile keyword before the ClientConnectionLostPending variable is defined. Is that done on

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-19 Thread Greg Jaskiewicz
On 19 Oct 2011, at 17:54, Florian Pflug wrote: On Oct19, 2011, at 17:47 , Greg Jaskiewicz wrote: On 15 Oct 2011, at 11:31, Florian Pflug wrote: Ok, here's a first cut. So I looked at the patch, and first thing that pops out, is lack of the volatile keyword before the

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-19 Thread Florian Pflug
On Oct19, 2011, at 18:05 , Greg Jaskiewicz wrote: On 19 Oct 2011, at 17:54, Florian Pflug wrote: On Oct19, 2011, at 17:47 , Greg Jaskiewicz wrote: On 15 Oct 2011, at 11:31, Florian Pflug wrote: Ok, here's a first cut. So I looked at the patch, and first thing that pops out, is lack of

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-19 Thread Greg Jaskiewicz
On 15 Oct 2011, at 11:31, Florian Pflug wrote: Ok, here's a first cut. So I looked at the patch, and first thing that pops out, is lack of the volatile keyword before the ClientConnectionLostPending variable is defined. Is that done on purpose ? Is that on purpose ? Otherwise the patch

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-19 Thread Greg Jaskiewicz
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

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-15 Thread Florian Pflug
On Oct11, 2011, at 09:21 , Magnus Hagander wrote: On Tue, Oct 11, 2011 at 03:29, Florian Pflug f...@phlo.org wrote: On Oct10, 2011, at 21:25 , Magnus Hagander wrote: On Thu, Oct 6, 2011 at 23:46, Florian Pflug f...@phlo.org wrote: It'd be nice to generally terminate a backend if the client

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-11 Thread Magnus Hagander
On Tue, Oct 11, 2011 at 03:29, Florian Pflug f...@phlo.org wrote: On Oct10, 2011, at 21:25 , Magnus Hagander wrote: On Thu, Oct 6, 2011 at 23:46, Florian Pflug f...@phlo.org wrote: It'd be nice to generally terminate a backend if the client vanishes, but so far I haven't had any bright ideas.

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-10 Thread Magnus Hagander
On Thu, Oct 6, 2011 at 23:46, Florian Pflug f...@phlo.org wrote: On Oct6, 2011, at 21:48 , Magnus Hagander wrote: The question is, should we do more? To me, it'd make sense to terminate a backend once it's connection is gone. We could, for example, make pq_flush() set a global flag, and make

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-10 Thread Florian Pflug
On Oct10, 2011, at 21:25 , Magnus Hagander wrote: On Thu, Oct 6, 2011 at 23:46, Florian Pflug f...@phlo.org wrote: It'd be nice to generally terminate a backend if the client vanishes, but so far I haven't had any bright ideas. Using FASYNC and F_SETOWN unfortunately sends a signal *everytime*

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-06 Thread Florian Pflug
On Oct5, 2011, at 15:30 , Magnus Hagander wrote: When walsender calls out to do_pg_stop_backup() (during base backups), it is not possible to terminate the process with a SIGTERM - it requires a SIGKILL. This can leave unkillable backends for example if archive_mode is on and archive_command

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-06 Thread Magnus Hagander
On Thu, Oct 6, 2011 at 14:34, Florian Pflug f...@phlo.org wrote: On Oct5, 2011, at 15:30 , Magnus Hagander wrote: When walsender calls out to do_pg_stop_backup() (during base backups), it is not possible to terminate the process with a SIGTERM - it requires a SIGKILL. This can leave unkillable

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-06 Thread Magnus Hagander
On Thu, Oct 6, 2011 at 04:22, Fujii Masao masao.fu...@gmail.com wrote: On Wed, Oct 5, 2011 at 10:30 PM, Magnus Hagander mag...@hagander.net wrote: When walsender calls out to do_pg_stop_backup() (during base backups), it is not possible to terminate the process with a SIGTERM - it requires a

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-06 Thread Florian Pflug
On Oct6, 2011, at 21:48 , Magnus Hagander wrote: The question is, should we do more? To me, it'd make sense to terminate a backend once it's connection is gone. We could, for example, make pq_flush() set a global flag, and make CHECK_FOR_INTERRUPTS handle a broken connection that same way as a

Re: [HACKERS] Bug in walsender when calling out to do_pg_stop_backup (and others?)

2011-10-05 Thread Fujii Masao
On Wed, Oct 5, 2011 at 10:30 PM, Magnus Hagander mag...@hagander.net wrote: When walsender calls out to do_pg_stop_backup() (during base backups), it is not possible to terminate the process with a SIGTERM - it requires a SIGKILL. This can leave unkillable backends for example if archive_mode