Re: max_wal_senders must die

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: max_wal_senders must die
Date: 2010-10-27 22:01:38
Message-ID: 29182.1288216898@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Josh Berkus <josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-10-27 23:13:42 Re: max_wal_senders must die
Previous Message Greg Stark 2010-10-27 21:33:41 Re: max_wal_senders must die