Re: [HACKERS] Streaming replication document improvements - Mailing list pgsql-docs

From Robert Haas
Subject Re: [HACKERS] Streaming replication document improvements
Date
Msg-id w2z603c8f071004191904yefcaba2fy1abc2020174a35c5@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Streaming replication document improvements  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: [HACKERS] Streaming replication document improvements
Re: [HACKERS] Streaming replication document improvements
List pgsql-docs
On Fri, Apr 2, 2010 at 2:06 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Fri, Apr 2, 2010 at 2:58 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> It's probably also easy to fix so that it doesn't NEED to be documented.
>>
>> The thing is, when dealing with new features, we reduce our overall
>> maintenance burden if we get it right the first time.  Obviously it's
>> too late for major changes, but minor adjustments to maintain the POLA
>> seem like exactly what we SHOULD be doing right now.
>
> The attached patch implements the Heikki's proposal:
>
> ----------
> ReservedBackends = superuser_reserved_connections + max_wal_senders
> MaxBackends = max_connections + autovacuum_max_workers + max_wal_senders + 1
> ----------
>
> This change looks like minor adjustments rather than major changes.

Instead of doing this, could we just change the logic in InitPostgres?

Current logic says we hit the connection limit if:

        if (!am_superuser &&
                ReservedBackends > 0 &&
                !HaveNFreeProcs(ReservedBackends))

Couldn't we just change this to:

        if ((!am_superuser || am_walsender) &&
                ReservedBackends > 0 &&
                !HaveNFreeProcs(ReservedBackends))

Seems like that'd be a whole lot simpler, if it'll do the job...

...Robert

pgsql-docs by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: docs cleanup patch
Next
From: Fujii Masao
Date:
Subject: Re: [HACKERS] Streaming replication document improvements