On Wed, Sep 11, 2013 at 02:00:41PM -0400, Robert Haas wrote:
> On Wed, Sep 11, 2013 at 10:38 AM, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> >> On Tue, Sep 10, 2013 at 07:13:16PM -0700, David Johnston wrote:
> >> > Your feelings on how far to back-patch?
> >>
> >> All suppor
On Wed, Sep 11, 2013 at 10:38 AM, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
>> On Tue, Sep 10, 2013 at 07:13:16PM -0700, David Johnston wrote:
>> > Your feelings on how far to back-patch?
>>
>> All supported versions. The current behavior is a bug every way I look at
>> it.
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, Sep 10, 2013 at 07:13:16PM -0700, David Johnston wrote:
> > Your feelings on how far to back-patch?
>
> All supported versions. The current behavior is a bug every way I look at it.
Agreed. I noticed a stale backend hanging around after a
cancel
On Tue, Sep 10, 2013 at 07:13:16PM -0700, David Johnston wrote:
> Noah Misch-2 wrote
> > The errfinish() pertaining to that WARNING issues CHECK_FOR_INTERRUPTS(),
> > and
> > the query cancel pending since before the SIGQUIT arrived then takes
> > effect.
> > This is less bad on 9.4, because the po
Noah Misch-2 wrote
> The errfinish() pertaining to that WARNING issues CHECK_FOR_INTERRUPTS(),
> and
> the query cancel pending since before the SIGQUIT arrived then takes
> effect.
> This is less bad on 9.4, because the postmaster will SIGKILL the backend
> after
> 5s. On older releases, the back
I've been doing an excess of immediate shutdowns lately, and that has turned
up bugs old and new. This one goes back to 8.4 or earlier. If a query cancel
is pending when a backend receives SIGQUIT, the cancel takes precedence and
the backend survives:
[local] test=# select nmtest_spin(false);
Ca
