Re: V3: Idle in transaction cancellation

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <andres(at)anarazel(dot)de>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: <selenamarie(at)gmail(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: V3: Idle in transaction cancellation
Date: 2010-12-05 21:23:07
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

"Kevin Grittner" wrote:
> Andres Freund wrote:
>> On Thursday 02 December 2010 00:48:53 Kevin Grittner wrote:
>>> Is there any provision for one backend to cause a *different*
>>> backend which is idle in a transaction to terminate cleanly when
>>> it attempts to process its next statement?
>> You might want to check out SendProcSignal() et al.
> Yeah, that was the missing link for me. Thanks!

OK, I have confirmed that the patch set Andres posted compiles and
passes regression tests (both `make check` and `make
installcheck-world`), and that the API provided works for at least
one purpose -- allowing SSI conflict detection to cancel an a
transaction other than the one on which the failure is detected, to
allow a guarantee that there will be no rollbacks without first
having a successful commit of a transaction which wrote data.

I created a "skip" branch in my git repo to hold the work for this
test. A single commit there which includes all three of Andres's
patches plus the code needed to implement the SSI feature is at:;a=

I now wish I'd committed Andres's patches separately first. If
anyone likes, I could try to put something together to separate
things out like that.

I did notice one picky thing while working on this -- the left brace
for some if statements wasn't placed consistently with surrounding
code. Rather than:

if (x)

the patch tends to do this:

if (x){

I agree with Andres that the API to use it is a little bit spread out
and non-obvious, but I don't see a nicer way to do it. Maybe someone
else can think of something.

I didn't test the patch in relation to the original purpose (for
which only the first two of the three patch files should be needed)
-- error handling with hot standby. I'm hoping that someone familiar
with the issues there can test that part of it.


Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2010-12-05 21:23:36 Re: Instrument checkpoint sync calls
Previous Message Rob Wultsch 2010-12-05 20:17:25 Re: profiling connection overhead