Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Sep 11, 2018 at 10:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
> I think, though, that it is pretty obvious that the intermediate zone
> which you refer to as "perhaps" existing does indeed exist. Queries
> running on the standby consume lock table slots, and killing them
> frees up those slots. Q.E.D.
Sounds like lock whack-a-mole to me. If there are enough standby queries
running to create the problem, there's probably a continuous inbound
query stream; you aren't going to be able to free up locktable space on
net without some way of suppressing new lock acquisitions altogether.
That's still more mechanism that'd have to be designed, written, and
tested. And believe you me, I will insist on a test case, now that we
know this has been broken for at least two years with nobody noticing.
regards, tom lane
