Re: StandbyAcquireAccessExclusiveLock doesn't necessarily

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: StandbyAcquireAccessExclusiveLock doesn't necessarily
Date: 2018-09-11 15:33:02
Message-ID: 26562.1536679982@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Sep 11, 2018 at 10:25 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2018-09-11 15:39:35 Re: patch to allow disable of WAL recycling
Previous Message Andres Freund 2018-09-11 15:29:29 Re: StandbyAcquireAccessExclusiveLock doesn't necessarily