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 don't see why we're insisting
> on anything particular as to its size.
The startup process alone needs to be able to hold all the master's
exclusive locks at once since they're WAL logged (and have to be).
Idon't think common locks held by other processes are an actual problem
- if max_connections and max_locks_per_xact is the same they can only
hold as many locks as the master could. They'd all conflict with WAL
replay of the exclusive locks anyway.
Now you probably could create a problematic situation by creating
hundres of advisory locks or something. But that's a fairly different
scenario from an idle server not being able to replay the primary's WAL
records because it can't keep track of all the locks.
Now you can argue that it's uncommon to hold that many AE locks on the
primary in the first place. But i'm not sure it's true. The most common
reasons I've seen for exceeding locks are dumps and restores - and the
latter is all AELs.
Greetings,
Andres Freund
