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

Re: V3: Idle in transaction cancellation

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Andres Freund" <andres(at)anarazel(dot)de>
Cc: "Selena Deckelmann" <selenamarie(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: V3: Idle in transaction cancellation
Date: 2010-12-02 20:54:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Andres Freund <andres(at)anarazel(dot)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.

In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2010-12-02 21:12:41
Subject: Re: directory archive format for pg_dump
Previous:From: Alvaro HerreraDate: 2010-12-02 20:43:50
Subject: Re: Another proposal for table synonyms

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