Andres Freund <and...@anarazel.de> writes:
> On 2018-09-11 16:23:44 +0100, Simon Riggs wrote:
>> It's hard to see how any reasonable workload would affect the standby. And
>> if it did, you'd change the parameter and restart, just like you already
>> have to do if someone changes max_connections on master first.
> Isn't one of the most common ways to run into "out of shared memory"
> "You might need to increase max_locks_per_transaction." to run pg_dump?
> And that's pretty commonly done against standbys?
If the startup process has acquired enough AELs to approach locktable
full, any concurrent pg_dump has probably failed already, because it'd
be trying to share-lock every table and so would have a huge conflict
cross-section; it's hard to believe it wouldn't get cancelled pretty
early in that process. (Again, if you think this scenario is probable,
you have to explain the lack of field complaints.)
The case where this behavior might really be of some use, IMO, is the
lots-of-small-transactions scenario --- but we lack the stop-new-locks
mechanism that would be needed to make the behavior actually effective
for that case.
regards, tom lane
