Re: idle in txn query cancellation
От | Simon Riggs |
---|---|
Тема | Re: idle in txn query cancellation |
Дата | |
Msg-id | 1266223808.7341.9529.camel@ebony обсуждение исходный текст |
Ответ на | idle in txn query cancellation (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: idle in txn query cancellation
|
Список | pgsql-hackers |
On Sat, 2010-02-13 at 22:37 +0100, Andres Freund wrote: > The first patch adds the capability to add a flag to ereport like: > ereport(ERROR | LOG_NO_CLIENT) > Tom earlier suggested using COMERROR but thats just a version of LOG > which doesnt report to the client. The patch makes that to be a > synonym of LOG | LOG_NO_CLIENT. > While its not the most pretty API I dont think its that bad because > the directionality is somewhat a property of the loglevel. Beside it > would generate a lot of useless noise and breakage. > > The second patch changes the FATAL during cancelling an idle in txn > query into ERROR | LOG_NO_CLIENT. > To avoid breaking the known state there also may no "ready for query" > message get sent. The patch ensures that by setting and checking a > "silent_error_while_idle" variable. > > That way the client will not see that an error occured until the next > command sent but I dont think there is a solution to that in 9.0 > timeframe if at all. > > The patch only adds that for the recovery conflict path for now. > > What do you think? Is it worth applying something like that now? If > yes I would try to test the patch some more (obviously the patch > survives the regression tests, but they do not seem to check the > extended query protocol at all). I think that is much better than FATAL. If it works I think we should apply it for this release. -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: