Date: Thu, 22 Oct 2020 16:01:55 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Wells Oliver <wells.oliver@gmail.com>,
	Stephen Frost <sfrost@snowman.net>,
	pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: Odd pg dump error: cache lookup failure
Message-ID: <20201022190155.GA29948@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD"
Content-Disposition: inline
In-Reply-To: <209234.1603312434@sss.pgh.pa.us>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk


--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On 2020-Oct-21, Tom Lane wrote:

> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > Here's a quick patchset that makes pg_dump do LOCK TABLE on all
> > relations it dumps; patch 0001 allows server-side LOCK TABLE to run on
> > any relkind, and then 0002 makes pg_dump test for that capability at
> > connection start, and if it exists, then it's used for all relations to
> > dump.
> 
> I think the "test for that capability" bit needs more subtlety.

Great ideas, thanks -- all adopted in the attached version.  I didn't
test this with 9.5 but as you say NOWAIT is already supported there and
the command itself does work.

Since the wrong-object error was thrown before the lock-unavailable
error, and both before the ACL check, it works to test for those codes
specifically; it's not a problem if the lock is unavailable or denied.
Right now if any other error occurs in the LOCK TABLE, pg_dump aborts
with an error.  I don't know what that could be.  I suppose if it dies
with OOM then it doesn't matter whether it's here or elsewhere.

Testing for a view as I was doing was not good, because PG12 does allow
locks on views.  I decided to use pg_aggregate_fnoid_index because it's
easier for manual tests: it doesn't prevent connecting to the database
when a strong lock is held.  This in contrast with other more obvious
candidates.  It's a pretty arbitrary choice but it shouldn't harm
anything since we don't actually hold the lock for more than an instant,
and that only if it's not contended.

I discovered once again that fallthrough comment handling in combination
with ccache are pretty obnoxious.

--HlL+5n6rz5pIUxbD
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
 filename="v2-0001-accept-any-relkind-in-LOCK-TABLE.patch"