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

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: (view raw, whole thread or download thread mbox)
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)

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


pgsql-hackers by date

Next:From: Josh BerkusDate: 2010-10-27 23:13:42
Subject: Re: max_wal_senders must die
Previous:From: Greg StarkDate: 2010-10-27 21:33:41
Subject: Re: max_wal_senders must die

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