Re: V3: Idle in transaction cancellation
От | Andres Freund |
---|---|
Тема | Re: V3: Idle in transaction cancellation |
Дата | |
Msg-id | 201012021557.18619.andres@anarazel.de обсуждение исходный текст |
Ответ на | Re: V3: Idle in transaction cancellation ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: V3: Idle in transaction cancellation
Re: V3: Idle in transaction cancellation |
Список | pgsql-hackers |
On Thursday 02 December 2010 00:48:53 Kevin Grittner wrote: > Andres Freund <andres@anarazel.de> wrote: > > On Tuesday 19 October 2010 16:18:29 Kevin Grittner wrote: > >> For SSI purposes, it would be highly desirable to be able to set > >> the SQLSTATE and message generated when the canceled transaction > >> terminates. > > > > Ok, I implemented that capability, but the patch feels somewhat > > wrong to me, > > > so its a separate patch on top the others: > The patch is in context diff format, applies with minor offsets, > compiles and passes regression tests. > > I have to admit that after reading the patch, I think I previously > misunderstood the scope of it. Am I correct in reading that the > main thrust of this is to improve error handling on standbys? 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? (That is what I was hoping to find, > for use in the SSI patch.) Do you wan't to terminate it immediately or on next statement? You might want to check out SendProcSignal() et al. > 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...
В списке pgsql-hackers по дате отправления: