On Wed, Oct 27, 2010 at 12:33 PM, Tom Lane <tgl@sss.pgh.pa.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