Re: max_wal_senders must die - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: max_wal_senders must die
Date
Msg-id 1288166933.1587.1246.camel@ebony
Whole thread Raw
In response to Re: max_wal_senders must die  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: max_wal_senders must die
List pgsql-hackers
On Tue, 2010-10-19 at 15:32 -0400, Tom Lane 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.  

Sorry guys, but that is completely wrong. There is no additional work to
be done each time a transaction commits, even with sync rep. And I don't
mean "nearly zero", I mean nada.

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

Agreed, but its to do with wal_level.

> Josh has completely failed to make a case that
> that should be the default.  

Agreed.

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

Agree with that as a problem.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: add label to enum syntax
Next
From: "Kevin Grittner"
Date:
Subject: Re: add label to enum syntax