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

Re: [HACKERS] Thoughts about bug #3883

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-patches(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Thoughts about bug #3883
Date: 2008-01-25 23:00:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
I wrote:
> No, the problem is merely to get LockWaitCancel to return "true" so that
> StatementCancelHandler will go ahead with the immediate interrupt.  No
> new cleanup is needed other than resetting the new flag.

Actually there's a better way to do it: we can remove a little bit of
complexity instead of adding more.  The basic problem is that
StatementCancelHandler wants to tell the difference between waiting for
client input (which there is no use for it to interrupt) and other
states in which ImmediateInterruptOK is set.  ProcWaitForSignal() is
falling on the wrong side of the classification --- and I argue that any
other newly added interruptable wait would too.  We should reverse the
sense of the test so that it's "not in client input" instead of "in lock
wait".  At the time that code was written, there wasn't any conveniently
cheap way to check for client input state, so we kluged up
LockWaitCancel to detect the other case.  But now that we have the
DoingCommandRead flag, it's easy to check that.  This lets us remove
LockWaitCancel's return value (which was always a bit untidy, since all
but one of its callers ignored the result), ending up with exactly
parallel code in die() and StatementCancelHandler().  Seems cleaner than

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2008-01-25 23:22:16
Subject: we have out func for typecast, but we missing this read function
Previous:From: Simon RiggsDate: 2008-01-25 22:13:52
Subject: Re: Proposal: Integrity check

pgsql-patches by date

Next:From: Simon RiggsDate: 2008-01-25 23:35:12
Subject: sinval contention reduction
Previous:From: Tom LaneDate: 2008-01-25 21:16:25
Subject: Re: Thoughts about bug #3883

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