Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
