From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: David Gilman <davidgilman1@gmail.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: "tuple concurrently updated" in pg_restore --jobs
In-reply-to: <20200710214521.GS26220@telsasoft.com>
References: <20200706050129.GW4107@telsasoft.com>
 <2116463.1594414480@sss.pgh.pa.us> <20200710210607.GR26220@telsasoft.com>
 <2164430.1594416988@sss.pgh.pa.us> <20200710214521.GS26220@telsasoft.com>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Fri, 10 Jul 2020 16:45:21 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2393678.1594487486.1@sss.pgh.pa.us>
Date: Sat, 11 Jul 2020 13:11:26 -0400
Message-ID: <2393679.1594487486@sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.com> writes:
> On Fri, Jul 10, 2020 at 05:36:28PM -0400, Tom Lane wrote:
>> I'm not sure how far to back-patch it -- I think the parallel restore
>> of ACLs behavior is not very old, but we might want to teach older
>> pg_dump versions to insert the extra dependency anyway, for safety.

> Yes, and the test case in David's patch on other thread [0] can't be
> backpatched further than this patch is.

Actually, the answer seems to be that we'd better back-patch all the way,
because this is a live bug much further back than I'd guessed. pg_restore
is willing to run these ACL restores in parallel in all active branches.
The given test case only shows a failure back to 9.6, because older
versions don't dump ACLs on system catalogs; but of course you can just
try it with a user table instead.

Oddly, I could not get the "tuple concurrently updated" syndrome to
appear on 9.5.  Not sure why not; the GRANT/REVOKE code looks the
same as in 9.6.  What I *could* demonstrate in 9.5 is that sometimes
the post-restore state is flat out wrong: the column-level grants go
missing, presumably as a result of the table-level REVOKE executing
after the column-level GRANTs.  Probably that syndrome occurs sometimes
in later branches too, depending on timing; but I didn't look.

			regards, tom lane