beta3 & the open items list
in [PgSql]
|
Prev: About tapes
Next: [HACKERS] beta3 & the open items list
From: Florian Pflug on 20 Jun 2010 06:46 On Jun 20, 2010, at 7:18 , Tom Lane wrote: > Florian Pflug <fgp(a)phlo.org> writes: >> On Jun 19, 2010, at 21:13 , Tom Lane wrote: >>> This is nonsense --- the slave's kernel *will* eventually notice that >>> the TCP connection is dead, and tell walreceiver so. I don't doubt >>> that the standard TCP timeout is longer than people want to wait for >>> that, but claiming that it will never happen is simply wrong. > >> No, Robert is correct AFAIK. If you're *waiting* for data, TCP >> generates no traffic (expect with keepalive enabled). > > Mph. I was thinking that keepalive was on by default with a very long > interval, but I see this isn't so. However, if we enable keepalive, > then it's irrelevant to the point anyway. Nobody's produced any > evidence that keepalive is an unsuitable solution. Yeah, I agree. Just enabling keepalive should suffice for 9.0. BTW, the postmaster already enables keepalive on incoming connections in StreamConnection() - presumably to prevent crashed clients from occupying a backend process forever. So there's even a clear precedent for doing so, and proof that it doesn't cause any harm. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 20 Jun 2010 09:54 Florian Pflug wrote: > On Jun 20, 2010, at 7:18 , Tom Lane wrote: >> I was thinking that keepalive was on by default with a very >> long interval, but I see this isn't so. However, if we enable >> keepalive, then it's irrelevant to the point anyway. Nobody's >> produced any evidence that keepalive is an unsuitable solution. > > Yeah, I agree. Just enabling keepalive should suffice for 9.0. +1, with configurable timeout; otherwise people will often feel they need to kill the receiver process to get it to attempt reconnect or archive search, anyway. Two hours is a long time to block replication based on a broken connection before attempting to move on. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 20 Jun 2010 11:36 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > Florian Pflug wrote: >> Yeah, I agree. Just enabling keepalive should suffice for 9.0. > +1, with configurable timeout; Right, of course. That's already in the pending patch isn't it? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Joshua D. Drake" on 20 Jun 2010 12:20 On Sun, 2010-06-20 at 11:36 -0400, Tom Lane wrote: > "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > > Florian Pflug wrote: > >> Yeah, I agree. Just enabling keepalive should suffice for 9.0. > > > +1, with configurable timeout; > > Right, of course. That's already in the pending patch isn't it? Can someone tell me what we are going to do about firewalls that impose their own rules outside of the control of the DBA? I know that keepalive *should* work, however I also know that regardless of keepalive I often have to restart sessions etc. There are environments that are outside the control of the user. Perhaps this has already been solved and I don't know about it. Does the master<->slave relationship have a built in ping mechanism that is outside of the TCP protocol? Sincerely, Joshua D. Drake > > regards, tom lane > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 20 Jun 2010 16:01
"Joshua D. Drake" wrote: > Can someone tell me what we are going to do about firewalls that > impose their own rules outside of the control of the DBA? Has anyone actually seen a firewall configured for something so stupid as to allow *almost* all the various packets involved in using a TCP connection, but which suppressed just keepalive packets? That seems to be what you're suggesting is the risk; it's an outlandish enough suggestion that I think the burden of proof is on you to show that it happens often enough to make this a worthless change. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |