Re: max_wal_senders must die

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: max_wal_senders must die
Дата
Msg-id 29182.1288216898@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: max_wal_senders must die  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: max_wal_senders must die  (Josh Berkus <josh@agliodbs.com>)
Re: max_wal_senders must die  (Alvaro Herrera <alvherre@commandprompt.com>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: max_wal_senders must die
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: max_wal_senders must die