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
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
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
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
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
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
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
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
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
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.
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
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*
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
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
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
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
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 is failing (or not set). A
similar thing would happen
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
18 matches
Mail list logo
