Re: max_wal_senders must die

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: max_wal_senders must die
Date: 2010-10-27 21:33:41
Message-ID: AANLkTim3XgPtCYM3Nh8ADun=nmVx+pbzNgTE_RP7KhL9@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 27, 2010 at 12:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> You're assuming that we should set up the default behavior to support
> replication and penalize those who aren't using it.  Considering that
> we haven't even *had* replication until now, it seems a pretty safe
> bet that the majority of our users aren't using it and won't appreciate
> that default.  We routinely expend large amounts of effort to avoid
> cross-version performance regressions, and I don't see that this one
> is acceptable when others aren't.

So I think we're talking about two different things.

a) whether to default to enabling the no-wal optimizations for newly
created tables which break replication

b) whether to impose a limit on the number of replication slaves by default

c) whether we can make these flags changable without restarting

I think (a) is a non-starter but if we can acheive (b) and (c) without
(a) then we're in pretty good shape. Someone would still have to
enable replication manually but they could do it without restarting,
and once they do it that one parameter would be sufficient, there
wouldn't be any hidden options lying in wait to trap them.

I think (c) is doable -- if we remember when the last non-logged
operation was we can refuse replication connections unless replication
is active and the replica isn't requesting any wal from prior to the
last unlogged operation.

--
greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-10-27 22:01:38 Re: max_wal_senders must die
Previous Message Tom Lane 2010-10-27 21:18:06 Re: crash in plancache with subtransactions