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: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Joachim Wieland <joe(at)mcknight(dot)de>, Kris Jurka <books(at)ejurka(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Subject: Re: Hot Standy introduced problem with query cancel behavior
Date: 2009-12-31 11:25:19
Message-ID: 1262258719.19367.10082.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 2009-12-30 at 20:06 +0100, Andres Freund wrote:

> Hm. I just read a bit of that multiplexing facility (out of a different reason) 
> and I have some doubt about it being used unmodified for canceling backends:
> 
> procsignal.c:
> /*
>  * Note: Since there's no locking, it's possible that the target
>  * process detaches from shared memory and exits right after this
>  * test, before we set the flag and send signal. And the signal slot
>  * might even be recycled by a new process, so it's remotely possible
>  * that we set a flag for a wrong process. That's OK, all the signals
>  * are such that no harm is done if they're mistakenly fired.
>  */
> procsignal.h:
> ...
>  * Also, because of race conditions, it's important that all the signals be
>  * defined so that no harm is done if a process mistakenly receives one.
>  */
> 
> When cancelling a backend that behaviour could be a bit annoying ;-)

Reading comments alone doesn't show the full situation here.

Before we send signal we check pid also, so the chances of this
happening are fairly small. i.e. we would need to have a backend slot
reused by a new backend with exactly same pid as the last slot holder.

I'm proposing to use this for killing transactions and connections, so I
don't think there's too much harm done there. If the backend is leaving
anyway, that's what we wanted. If its a new guy that is wearing the same
boots then a little collateral damage doesn't leave the server in a bad
place. HS cancellations aren't yet so precise that this matters.

-- 
 Simon Riggs           www.2ndQuadrant.com


In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-12-31 11:32:39
Subject: Re: add xml support function
Previous:From: fangfang liuDate: 2009-12-31 11:22:26
Subject: Re: add xml support function

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