Re: max_wal_senders must die - Mailing list pgsql-hackers

From Tom Lane
Subject Re: max_wal_senders must die
Date
Msg-id 29182.1288216898@sss.pgh.pa.us
Whole thread Raw
In response to Re: max_wal_senders must die  (Josh Berkus <josh@agliodbs.com>)
Responses Re: max_wal_senders must die
Re: max_wal_senders must die
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
>> You're assuming that we should set up the default behavior to support
>> replication and penalize those who aren't using it.

> What's the penalty?  Simon just said that there isn't one.

I don't know what Simon is thinking, but I think he's nuts.  There is is
obvious extra overhead in COMMIT:
    /*     * Wake up all walsenders to send WAL up to the COMMIT record     * immediately if replication is enabled
*/   if (max_wal_senders > 0)        WalSndWakeup();
 

which AFAICT is injecting multiple kernel calls into what's not only
a hot-spot but a critical section (ie, any error -> PANIC).

That's not even considering the extra WAL that is generated when you
move up from wal_level = "minimal".  That's probably the bigger
performance issue in practice.

> And there's a difference between saying that I "failed to make a case"
> vs. "the cost is too great".

I said, and meant, that you didn't make the case at all; you just
presumed it was obvious that we should change the defaults to be
replication-friendly.  I don't think it is.  As I said, I think that
only a minority of our users are going to want replication.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: max_wal_senders must die
Next
From: Josh Berkus
Date:
Subject: Re: max_wal_senders must die