Re: V3: Idle in transaction cancellation - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: V3: Idle in transaction cancellation
Date
Msg-id 4CF7B33E02000025000381AF@gw.wicourts.gov
Whole thread Raw
In response to Re: V3: Idle in transaction cancellation  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> 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!
>> Anyway, if the third patch file is only there because of my
>> request, I think it might be best to focus on the first two as a
>> solution for the standby issues this was originally meant to
>> address, and then to look at an API for the usage I have in mind
>> after that is settled.
> Besides that I dont like the implementation very much, I think its
> generally a good idea...
Is it sane to leave the implementation of this for the specific
areas which need it (like SSI), or do you think a generalized API
for it is needed?
I'll look at it more closely tonight, but at first scan it appears
that just reserving one flag for PROCSIG_SERIALIZATION_FAILURE (or
PROCSIG_SSI_CANCELLATION?) would allow me to code up the desired
behavior in a function called from procsignal_sigusr1_handler.  I
can arrange for passing any needed detail through the SSI-controlled
structures somehow.  Would that allow you to skip the parts you
didn't like?
It looks as though this is something which could easily be split off
as a separate patch within the SSI effort.
-Kevin


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Another proposal for table synonyms
Next
From: Alvaro Herrera
Date:
Subject: Re: directory archive format for pg_dump