Skip site navigation (1) Skip section navigation (2)

Re: Hot Standy introduced problem with query cancel behavior

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Joachim Wieland <joe(at)mcknight(dot)de>, Kris Jurka <books(at)ejurka(dot)com>
Subject: Re: Hot Standy introduced problem with query cancel behavior
Date: 2009-12-30 00:13:01
Message-ID: 1262131981.19367.3604.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 2009-12-29 at 11:13 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On Tuesday 29 December 2009 16:22:54 Tom Lane wrote:
> >> This seems like a fairly bad idea.  One of the intended use-cases is to
> >> be able to manually "kill -INT" a misbehaving backend.  Assuming that
> >> there will be valid info about the signal in shared memory will break
> >> that.
> 
> > Well. That already is the case now. MyProc->recoveryConflictMode is checked to 
> > recognize what kind of conflict is being resolved...
> 
> In that case, HS has already broken it, and we need to fix it not make
> it worse.
> 
> My humble opinion is that SIGINT should not be overloaded with multiple
> meanings.  We already have a multiplexed signal mechanism, which is what
> should be used for any additional signal reasons HS may need to
> introduce.

It's a revelation to me, but yes, I see it now and agree.

I'm looking at Fujii-san's multiplexing patch from Jul 31 to rewrite
this code using that mechanism. It sounds like it's a neat fit and it
should get around the bug report from Kris also if it all works.

-- 
 Simon Riggs           www.2ndQuadrant.com


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-12-30 00:29:24
Subject: Re: Stats for inheritance trees
Previous:From: Simon RiggsDate: 2009-12-29 23:47:17
Subject: Re: Hot Standy introduced problem with query cancel behavior

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group