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

Re: max_wal_senders must die

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(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 08:08:53
Message-ID: 1288166933.1587.1246.camel@ebony (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, 2010-10-19 at 15:32 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Tue, Oct 19, 2010 at 12:18 PM, Josh Berkus <josh(at)agliodbs(dot)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.  


> 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 
 PostgreSQL Development, 24x7 Support, Training and Services

In response to


pgsql-hackers by date

Next:From: Ivan VorasDate: 2010-10-27 10:13:10
Subject: Re: Postgres insert performance and storage requirement compared to Oracle
Previous:From: Dean RasheedDate: 2010-10-27 07:56:00
Subject: Re: add label to enum syntax

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