Re: Server won't start with fallback setting by initdb.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Server won't start with fallback setting by initdb.
Date: 2018-02-28 18:11:16
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Feb 9, 2018 at 3:08 AM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> I'm not sure such a case happens in the real world nowadays,
> initdb uses the fallback value of max_connections=10. But it is
> out of favor of server since it is not larger than
> max_wal_senders(10).
>> postgres: max_wal_senders must be less than max_connections
> I think that we can safely increase the fallback value to 20 with
> which regtests are known not to fail. I believe that is
> preferable than explicitly reducing max_wal_senders in the
> generated config file. I confirmed that tegtest won't fail with
> the value. (Except with permanent failure of dynamic shared
> memory)

I propose an alternative fix: let's instead change the code like this:

if (max_wal_senders > MaxConnections)
write_stderr("%s: max_wal_senders may not be more than
max_connections\n", progname);

That way, the behavior would match the documentation, which says:

"WAL sender processes count towards the total number of connections,
so the parameter cannot be set higher than max_connections."

Alternatively, we could change the documentation to match the code and
then do this. But it's not good that the documentation and the code
don't agree on whether equal values are acceptable.

Robert Haas
The Enterprise PostgreSQL Company

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Anastasia Lubennikova 2018-02-28 18:42:45 Re: [HACKERS] Cast jsonb to numeric, int, float, bool
Previous Message Michael Banck 2018-02-28 18:08:56 [PATCH] Verify Checksums during Basebackups