Re: "tuple concurrently updated" in pg_restore --jobs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "tuple concurrently updated" in pg_restore --jobs
Date
Msg-id 2393679.1594487486@sss.pgh.pa.us
Whole thread Raw
In response to "tuple concurrently updated" in pg_restore --jobs  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Default setting for enable_hashagg_disk
Next
From: Tom Lane
Date:
Subject: Re: jsonpath versus NaN