On 2015-08-11 02:06:53 -0400, Tom Lane wrote:
Hm. Surely KnownAssignedXIDs could be resized at need.
It's in shared memory so GetSnapshotData() can access it, so not trivially.
lock table on the standby, that could be completely occupied by locks
taken by hot-standby backend processes, so I
On 11 August 2015 at 06:42, Tom Lane t...@sss.pgh.pa.us wrote:
Tatsuo Ishii is...@postgresql.org writes:
I think this is because pg_control on the standby remembers that the
previous primary server's max_connections = 1100 even if the standby
server fails to start. Shouldn't we update
On 2015-08-11 13:53:15 +0900, Tatsuo Ishii wrote:
Today I encountered an interesting situation.
1) A streaming replication primary server and a standby server is
running. At this point max_connections = 100 on both servers.
2) Shutdown both servers.
3) Change max_connections to 1100
Michael Paquier michael.paqu...@gmail.com writes:
On Tue, Aug 11, 2015 at 2:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Somebody refresh my memory as to why we have this restriction (that is,
slave's max_connections = master's max_connections) in the first place?
Seems like it should not be a
On Tue, Aug 11, 2015 at 2:57 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Tue, Aug 11, 2015 at 2:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Tatsuo Ishii is...@postgresql.org writes:
I think this is because pg_control on the standby remembers that the
previous primary server's
Today I encountered an interesting situation.
1) A streaming replication primary server and a standby server is
running. At this point max_connections = 100 on both servers.
2) Shutdown both servers.
3) Change max_connections to 1100 on both servers and restart both
servers.
4) The
Tatsuo Ishii is...@postgresql.org writes:
I think this is because pg_control on the standby remembers that the
previous primary server's max_connections = 1100 even if the standby
server fails to start. Shouldn't we update pg_control file only when
standby succeeds to start?
Somebody refresh
Somebody refresh my memory as to why we have this restriction (that is,
slave's max_connections = master's max_connections) in the first place?
Seems like it should not be a necessary requirement, and working towards
getting rid of it would be far better than any other answer.
If you care
On Tue, Aug 11, 2015 at 2:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Tatsuo Ishii is...@postgresql.org writes:
I think this is because pg_control on the standby remembers that the
previous primary server's max_connections = 1100 even if the standby
server fails to start. Shouldn't we update
