Re: database shutdown with persistent client connections
От | g.hintermayer@inode.at (Gerhard Hintermayer) |
---|---|
Тема | Re: database shutdown with persistent client connections |
Дата | |
Msg-id | bd4db85f.0207312332.616c80e7@posting.google.com обсуждение исходный текст |
Ответ на | Re: database shutdown with persistent client connections (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
tgl@sss.pgh.pa.us (Tom Lane) wrote in message news:<27612.1028124591@sss.pgh.pa.us>... > g.hintermayer@inode.at (Gerhard Hintermayer) writes: > > Is there a notification sen't out in either smart or fast shutdown > > mode ? > > Sure: the backend sends an error message > FATAL: This connection has been terminated by the administrator. > before closing the connection. > > The problem you're describing is that the client-side code isn't looking > for any communication from the server except when it's involved in a SQL > command. I'm not sure what you can do about that except restructure the > client. > What I tried is (for libpgtcl): Everytime if I do PQconsumeInput (when the backend channel gets readable) I check for the return value. (0 == error) and generate a notification manually, e.g. connection_closed) and pass it to the TCL event queue. The only bad thing I had to do is to comment out removing all pending events in PgStopNotifyEventSource. Could there be any sideeffects ? Maybe I should do that only if the connection was unexpectedly closed (i.e. called from within PgNotifyTransferEvents) ? Gerhard
В списке pgsql-general по дате отправления: