Re: max_wal_senders must die

On Tue, Oct 19, 2010 at 3:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Oct 19, 2010 at 12:18 PM, Josh Berkus <josh@agliodbs.com> wrote:
>>> On 10/19/2010 09:06 AM, Greg Smith wrote:
>>>> I think Magnus's idea to bump the default to 5 triages the worst of the
>>>> annoyance here, without dropping the feature (which has uses) or waiting
>>>> for new development to complete.
>
>> Setting max_wal_senders to a non-zero value causes additional work to
>> be done every time a transaction commits, aborts, or is prepared.
>
> 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?".  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.

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.  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.

One of the problems with making these and similar settings changeable
on the fly is that, to be safe, we can declare that the value is
increased until we can verify that every still-running backend has
picked up the increased value and begun acting upon it.  We have no
architecture for knowing when that has happened; the postmaster just
signals its children and forgets about it.  If you had a shared memory
array (similar to the ProcArray, but perhaps with a separate set of
locks) in which backends wrote their last-known values of GUCs that
fall into this category, it would be possible to write a function that
returns the answer to the question "What is the least value of
wal_level that exists in any backend in the system?".  Maybe that's
not the right architecture; I'm not sure.  But we should see if we can
figure out something that will work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company