Re: Why does PostgresNode.pm set such a low value of max_wal_senders?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why does PostgresNode.pm set such a low value of max_wal_senders?
Дата
Msg-id 982653.1601559772@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Why does PostgresNode.pm set such a low value of max_wal_senders?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Sep 30, 2020 at 10:38:59PM -0700, Noah Misch wrote:
>> In favor of minimal values, we've had semaphore-starved buildfarm members in
>> the past.  Perhaps those days are over, seeing that this commit has not yet
>> broken a buildfarm member in that particular way.  Keeping max_wal_senders=10
>> seems fine.

> Indeed, I am not spotting anything suspicious here.

Yeah, so far so good.  Note that PostgresNode.pm does attempt to cater for
semaphore-starved machines, by cutting max_connections as much as it can.
In practice the total semaphore usage of a subscription test is probably
still less than that of one postmaster with default max_connections.

>> No, PostgreSQL commit 54c2ecb changed that.  I recommend an explicit
>> max_wal_senders=10 in PostgresNode, which makes it easy to test
>> wal_level=minimal:

> Ah, thanks, I have missed this piece.  So we really need to have a
> value set in this module after all.

Agreed, I'll go put it back.

On the other point, I think that we should continue to complain
about max_wal_senders > 0 with wal_level = minimal.  If we reduce
that to a LOG message, which'd be the net effect of trying to be
laxer, people wouldn't see it and would then wonder why they can't
start replication.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: James Coleman
Дата:
Сообщение: Re: enable_incremental_sort changes query behavior
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Transactions involving multiple postgres foreign servers, take 2