Re: [HACKERS] More thoughts about FE/BE protocol
От | Nigel J. Andrews |
---|---|
Тема | Re: [HACKERS] More thoughts about FE/BE protocol |
Дата | |
Msg-id | Pine.LNX.4.21.0304102333300.31910-100000@ponder.fairway2k.co.uk обсуждение исходный текст |
Ответ на | Re: [HACKERS] More thoughts about FE/BE protocol (Bruce Badger <bruce_badger@badgerse.com>) |
Список | pgsql-interfaces |
On 11 Apr 2003, Bruce Badger wrote: > On Fri, 2003-04-11 at 04:15, Tom Lane wrote: > > > Well, as far as network roundtrips go, it's always been true that you > > don't really have to wait for the backend's response before sending the > > next command. The proposal to decouple SYNC from individual commands > > should make this easier: you fire off N commands "blind", then a SYNC. > > When the sync response comes back, it's done. If any of the commands > > fail, all else up to the SYNC will be ignored, so you don't have the > > problem of commands executing against an unexpected state. > > Is SYNC going to be a new kind of message? Is the SYNC response yet > another? > > Either way, could this be used as a keep-alive for long-lived > connections? (some users of the current Smalltalk drivers report that > long lived connections over the Internet sometimes just die) If there's talk of keep-alive messages, what of keep-alive from server to client. There's been a few reports of backends been left hanging around because clients have dropped the connection or network issues have blocked connections in such a manner that the server hasn't seen the connection close. I believe this is only going to be an issue on systems configured to not use keep-alive packets. So it may be deemed nothing to do with postgresql and if it's an issue the sys/net admin has to get involved. -- Nigel J. Andrews
В списке pgsql-interfaces по дате отправления: