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
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 Herrera||Date: 2010-12-02 21:12:41|
|Subject: Re: directory archive format for pg_dump|
|Previous:||From: Alvaro Herrera||Date: 2010-12-02 20:43:50|
|Subject: Re: Another proposal for table synonyms|