beta3 & the open items list
in [PgSql]
|
Prev: About tapes
Next: [HACKERS] beta3 & the open items list
From: Tom Lane on 20 Jun 2010 17:52 Robert Haas <robertmhaas(a)gmail.com> writes: > On Sun, Jun 20, 2010 at 5:32 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> https://commitfest.postgresql.org/action/patch_view?id=281 > +1 for applying something along these lines, but we'll also need to > update walreceiver to actually use one or more of these new > parameters. Right, but the libpq-level support has to come first. > On a quick read, I think I see a problem with this: if a parameter is > specified with a non-zero value and there is no OS support available > for that parameter, it's an error. Presumably, for our purposes here, > we'd prefer to simply ignore any parameters for which OS support is > not available. Given the nature of these parameters, one might argue > that's a more useful behavior in general. > Also, what about Windows? Well, of course that patch hasn't been reviewed yet ... but shouldn't we just be copying the existing server-side behavior, as to both points? 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: Greg Stark on 20 Jun 2010 18:13 On Sun, Jun 20, 2010 at 10:41 PM, Florian Pflug <fgp(a)phlo.org> wrote: > Yeah, especially since there is no such thing as a special "keepalive" packet in TCP. Keepalive simply sends packets with zero bytes of payload every once in a while if the connection is otherwise inactive. If those aren't acknowledged (like every other packet would be) by the peer, the connection is assumed to be broken. On a reasonably active connection, keepalive neither causes additional transmissions, nor altered transmissions. Actualy keep-alive packets contain one byte of data which is a duplicate of the last previously acked byte. > > Keepalive is therefore extremely unlikely to break things - in the very worst case, a (really, really stupid) firewall might decide to drop packets with zero bytes of payload, causing inactive connections to abort after a while. AFAIK walreceiver will simply reconnect in this case. Stateful firewalls whole raison-d'etre is to block packets which aren't consistent with the current TCP state -- such as packets with a sequence number earlier than the last acked sequence number. Keepalives do in fact violate the basic TCP spec so they wouldn't be entirely crazy to block them. Of course a firewall that blocked them would be pretty criminally stupid given how ubiquitous they are. > Plus, the postmaster enables keepalive on all incoming connections *already*, so any problems ought to have caused bugreports about dropped client connections. Really? Since when? I thought there was some discussion about this about a year ago and I made it very clear this had to be an optional feature which defaulted to off. Keepalives introduce spurious disconnections in working TCP connections that have transient outages which is basic TCP functionality that's supposed to work. There are cases where that's what you want but it isn't the kind of thing that should be on by default, let alone on unconditionally. -- greg -- 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 19:09 Greg Stark wrote: > Keepalives introduce spurious disconnections in working TCP > connections that have transient outages It's been a while since I read up on this, so perhaps my memory has distorted the facts over time, but I thought that under TCP, if one side sends a packet which isn't ack'd after a (configurable) number of tries with certain (configurable) timings, the connection would be considered broken and an error returned regardless of keepalive settings. I thought keepalive only generated a trickle of small packets during idle time so that broken connections could be detected on the side of a connection which was waiting to receive data before doing something. That doesn't sound consistent with your characterization, though, since if my recollection is right, one could just as easily say that any write to a TCP socket by the application can also cause "spurious disconnections in working TCP connections that have transient outages." I know that with a two minute keepalive timeout, I can unplug a machine from one switch port and plug it in somewhere else and the networking hardware sorts things out fast enough that the transient network outage doesn't break the TCP connection, whether the application is sending data or it is quiescent and the OS is sending keepalive packets. From what I've read about the present walreceiver retry logic, if the connection breaks, WR will use some intelligence to try the archive and retry connecting through TCP, in turn, until it finds data. If the connection goes silent without breaking, WR sits there forever without looking at the archive or trying to obtain a new TCP connection to the master. I know which behavior I'd prefer. Apparently the testers who encountered the behavior felt the same. -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: Florian Pflug on 20 Jun 2010 19:42 On Jun 21, 2010, at 0:13 , Greg Stark wrote: >> Keepalive is therefore extremely unlikely to break things - in the very worst case, a (really, really stupid) firewall might decide to drop packets with zero bytes of payload, causing inactive connections to abort after a while. AFAIK walreceiver will simply reconnect in this case. > > Stateful firewalls whole raison-d'etre is to block packets which > aren't consistent with the current TCP state -- such as packets with a > sequence number earlier than the last acked sequence number. > Keepalives do in fact violate the basic TCP spec so they wouldn't be > entirely crazy to block them. Keepalives play games with the spec, but they don't outright violate it I'd say. The sender bluffs by retransmitting data it *knows* has been ACK'ed. But since nobody else can prove with certainty that the sender actually saw that ACK (think NIC-internal buffer overflow), nobody is able to call that bluff. > Of course a firewall that blocked them > would be pretty criminally stupid given how ubiquitous they are. Very true, and another reason to stop worrying about possibly brain-dead firewalls. >> Plus, the postmaster enables keepalive on all incoming connections >> *already*, so any problems ought to have caused bugreports about >> dropped client connections. > > Really? Since when? I thought there was some discussion about this > about a year ago and I made it very clear this had to be an optional > feature which defaulted to off. Since 'bout 10 years. The setsockopt call is in StreamConnection() in src/backend/libpq/pqcomm.c. Here's the corresponding commit: commit 5aa160abba32a1f2d7818b9f49213f38c99b3fd8 Author: Tatsuo Ishii <ishii(a)postgresql.org> Date: Sat May 20 13:10:54 2000 +0000 Add KEEPALIVE option to the socket of backend. This will automatically terminate the backend that has no frontend anymore. > Keepalives introduce spurious disconnections in working TCP > connections that have transient outages which is basic TCP > functionality that's supposed to work. There are cases where that's > what you want but it isn't the kind of thing that should be on by > default, let alone on unconditionally. I'd buy that if all timeouts and retry counts would default to +infinity. But they don't, and hence sufficiently long network outages *will* cause connection aborts anyway. That a particular connection might survive due to inactivity proves nothing, since whether the connection is active or inactive during an outage is usually outside of anyone's control. I really fail to see why anyone would prefer connections (and therefore transactions!) getting stuck forever over a few spurious disconnects. The former always require manual intervention and cause all sorts of performance and disk-space issues, while the latter won't even be an issue for well-written clients who just reconnect and retry. 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: Greg Stark on 20 Jun 2010 21:31
On Mon, Jun 21, 2010 at 12:42 AM, Florian Pflug <fgp(a)phlo.org> wrote: > I'd buy that if all timeouts and retry counts would default to +infinity. But they don't, and hence sufficiently long network outages *will* cause connection aborts anyway. That a particular connection might survive due to inactivity proves nothing, since whether the connection is active or inactive during an outage is usually outside of anyone's control. > > I really fail to see why anyone would prefer connections (and therefore transactions!) getting stuck forever over a few spurious disconnects. The former always require manual intervention and cause all sorts of performance and disk-space issues, while the latter won't even be an issue for well-written clients who just reconnect and retry. > So just as a data point I'm routinely annoyed by reopening my screen session and finding various session sessions have died since the day before. Usually this is caused by broken firewalls but there are also a bunch of SSH options which some servers have enabled which cause my sessions to never survive very long if there are any network outages. Servers where those options are disabled work fine. I admit this is a very different use case though and since we have control over the behaviour when the connection breaks perhaps the analogy falls apart completely. I'm not sure we can guarantee that reconnecting is always so simple though. What if the user set up an SSH gateway or needs some extra authentication to make the connection. Are users expecting the slave to randomly disconnect and reconnect willy nilly or are they expecting that once it connects it'll keep using that connection forever? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |