Request a Demo
Home   >   mailing lists

Re: Why standby.max_connections must be higher than primary.max_connections? - Mailing list pgsql-hackers

From satoshi yamada
Subject Re: Why standby.max_connections must be higher than primary.max_connections?
Date
Msg-id CAAsiBbwayEM6rB1LsQn8dDdvEW+hohR-2S0SfAmPis5WNgA=pw@mail.gmail.com
Whole thread
In response to Re: Why standby.max_connections must be higher than primary.max_connections?  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Tree view
>> Because the KnownAssignedXIDs and lock tables on the standby need to
>> be large enough to contain the largest snapshot and greatest number of
>> AccessExclusiveLocks that could exist on the master at any given time.
>
> Right. Initially during the development of Hot Standby, it looked like
> the "max_connections >= master's" requirement on standbys wasn't going
> to be necessary, or could be avoided. However, Simon gave up on that
> idea on pragmatic grounds here:
>
> http://www.postgresql.org/message-id/1252002165.2889.467.camel@ebony.2ndQuadrant
>
> I'd thought about revisiting this myself, but I think that the impetus
> to do so is lessened by recent work on logical replication.
>

Hi Peter

Your information make my question be clearly.
I understand the discussions about this restriction.

Thanks.



2013/12/12 Peter Geoghegan <pg@heroku.com>
On Tue, Dec 10, 2013 at 1:17 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Because the KnownAssignedXIDs and lock tables on the standby need to
> be large enough to contain the largest snapshot and greatest number of
> AccessExclusiveLocks that could exist on the master at any given time.

Right. Initially during the development of Hot Standby, it looked like
the "max_connections >= master's" requirement on standbys wasn't going
to be necessary, or could be avoided. However, Simon gave up on that
idea on pragmatic grounds here:

http://www.postgresql.org/message-id/1252002165.2889.467.camel@ebony.2ndQuadrant

I'd thought about revisiting this myself, but I think that the impetus
to do so is lessened by recent work on logical replication.

--
Peter Geoghegan

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: "stuck spinlock"
Next
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] configure: allow adding a custom string to PG_VERSION