|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>|
|Subject:||Re: V3: Idle in transaction cancellation|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
"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:
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:
the patch tends to do this:
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.
|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|