beta3 & the open items list
in [PgSql]
|
Prev: About tapes
Next: [HACKERS] beta3 & the open items list
From: Kenneth Marshall on 20 Jun 2010 16:44 On Sun, Jun 20, 2010 at 03:01:04PM -0500, Kevin Grittner wrote: > "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 > I have seen this sort of behavior but in every case it has been the result of a myopic view of firewall/IP tables solutions to perceived "attacks". While I do agree that having heartbeat within the replication process it worthwhile, it should definitely be 9.1 material at best. For 9.0 such ill-behaved environments will need much more interaction by the DBA with monitoring and triage of problems as they arrive. Regards, Ken P.S. My favorite example of odd behavior was preemptively dropping TCP packets in one direction only at a single port. Many, many odd things happen when the kernel does not know that the packet would never make it to it destination. Services would sometimes run for weeks without a problem depending on when the port ended up being used invariably at night or on the weekend. -- 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: Robert Haas on 20 Jun 2010 17:19 On Sun, Jun 20, 2010 at 11:36 AM, Tom Lane <tgl(a)sss.pgh.pa.us> 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? Is this sarcasm, or is there a pending patch I'm not aware of? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- 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 17:32 Robert Haas <robertmhaas(a)gmail.com> writes: > On Sun, Jun 20, 2010 at 11:36 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Right, of course. �That's already in the pending patch isn't it? > Is this sarcasm, or is there a pending patch I'm not aware of? https://commitfest.postgresql.org/action/patch_view?id=281 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: Florian Pflug on 20 Jun 2010 17:41 On Jun 20, 2010, at 22:01 , Kevin Grittner wrote: > "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. 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. 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. Plus, the postmaster enables keepalive on all incoming connections *already*, so any problems ought to have caused bugreports about dropped client connections. 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: Robert Haas on 20 Jun 2010 17:44
On Sun, Jun 20, 2010 at 5:32 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Sun, Jun 20, 2010 at 11:36 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> Right, of course. �That's already in the pending patch isn't it? > >> Is this sarcasm, or is there a pending patch I'm not aware of? > > 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. 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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |