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 pat
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
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 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 i
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 po
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 Clie
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 d
On Oct11, 2011, at 09:21 , Magnus Hagander wrote:
> On Tue, Oct 11, 2011 at 03:29, Florian Pflug wrote:
>> On Oct10, 2011, at 21:25 , Magnus Hagander wrote:
>>> On Thu, Oct 6, 2011 at 23:46, Florian Pflug wrote:
It'd be nice to generally terminate a backend if the client vanishes, but
On Tue, Oct 11, 2011 at 03:29, Florian Pflug wrote:
> On Oct10, 2011, at 21:25 , Magnus Hagander wrote:
>> On Thu, Oct 6, 2011 at 23:46, Florian Pflug 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
On Oct10, 2011, at 21:25 , Magnus Hagander wrote:
> On Thu, Oct 6, 2011 at 23:46, Florian Pflug 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* the fd
On Thu, Oct 6, 2011 at 23:46, Florian Pflug 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 CHECK
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 w
On Thu, Oct 6, 2011 at 04:22, Fujii Masao wrote:
> On Wed, Oct 5, 2011 at 10:30 PM, 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 14:34, Florian Pflug 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 backen
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_comman
On Wed, Oct 5, 2011 at 10:30 PM, 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 archiv
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 i
18 matches
Mail list logo
