Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group