Re: StandbyAcquireAccessExclusiveLock doesn't necessarily

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On 10 September 2018 at 19:16, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Fri, Sep 7, 2018 at 6:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> So my inclination is to remove the reportMemoryError = false parameter,
>>> and just let an error happen in the unlikely situation that we hit OOM
>>> for the lock table.

>> Wouldn't that take down the entire cluster with no restart?

> Please explain why you think that would be with no restart.

More to the point, what are our alternatives, and how much can we
really improve it? If the WAL stream requires more concurrent AELs
than the standby's lock table can hold, there isn't going to be any
solution short of manual intervention to increase the standby's
max_locks_per_transaction.

The point of the previous coding here was that perhaps there's some
range of number-of-locks-needed where kicking hot-standby queries
off of locks would allow recovery to proceed. However, it is (as
far as I know) unproven that that actually works, let alone is
effective enough to justify maintaining very-hard-to-test code for.
The field demand for such behavior can be measured by the number of
complaints we've had since breaking it in 9.6, namely zero.

So no, I do not want to re-implement and maintain that behavior on
the strength of just a guess that sometimes it might be useful.
If somebody else feels a burning passion for it, they can do the
work --- but I'd be inclined to argue that it'd be a HEAD-only
performance improvement, not a back-patchable bug fix.

regards, tom lane