Re: max_wal_senders must die

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: max_wal_senders must die
Date: 2010-10-19 20:54:56
Message-ID: 4CBE05A0.1090406@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>> Yes. This isn't just a numeric parameter; it's also a boolean
>> indicating "do I want to pay the overhead to be prepared to be a
>> replication master?".

Since this is the first time I've heard of the overhead, it would be
hard for me to have taken that into consideration. If there was
discussion about this ever, I missed it. That explains why we changed
the default in RC1 though, which was a surprise to me.

What is the overhead exactly? What specific work do we do? Link?

>> Josh has completely failed to make a case that
>> that should be the default. In fact, the system would fail to start
>> at all if we just changed the default for max_wal_senders and not the
>> default for wal_level.

Well, now that you mention it, I also think that "hot standby" should be
the default. Yes, I know about the overhead, but I also think that the
number of our users who want easy replication *far* outnumber the users
who care about an extra 10% WAL overhead.

> On a slightly tangential note, it would be really nice to be able to
> change things like wal_level and max_wal_senders on the fly.

This would certainly help solve the problem. Heck, if we could even
just change them with a reload (rather than a restart) it would be a
vast improvement.

> ISTM
> that needing to change the setting is actually the smaller portion of
> the gripe; the bigger annoyance is that you bring the system down,
> change one setting, bring it back up, take a hot backup, and then
> realize that you have to shut the system down again to change the
> other setting, because you forgot to do it the first time. Since the
> error message you get on the slave side is pretty explicit, the sheer
> fact of needing to change max_wal_senders is only a minor
> inconvenience; but the possible need to take down the system a second
> time is a major one.

You've summed up the problem nicely. I'll note that even though I've
already set up 3 production systems using SR, I still mess this up about
1/3 the time and have to restart and reclone. There's just too many
settings.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-10-19 21:29:15 Re: Creation of temporary tables on read-only standby servers
Previous Message Robert Haas 2010-10-19 20:46:03 Re: patch: Add JSON datatype to PostgreSQL (GSoC, WIP)