Re: #XX000: ERROR: tuple concurrently updated - Mailing list pgsql-general

From Dominique Devienne
Subject Re: #XX000: ERROR: tuple concurrently updated
Date
Msg-id CAFCRh-957e6i9NWXo9iNCS10AGKjSRqZ_CoCP+-67s82Rd8Bjw@mail.gmail.com
Whole thread Raw
In response to Re: #XX000: ERROR: tuple concurrently updated  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: #XX000: ERROR: tuple concurrently updated
List pgsql-general
On Thu, Feb 20, 2025 at 4:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Dominique Devienne <ddevienne@gmail.com> writes:
> Error: DDL Error: GRANT USAGE ON SCHEMA "SCH1", "SCH2" TO "SCH2:RO",
> "SCH2:RW", "SCH2:SU": #XX000: ERROR:  tuple concurrently updated

Since both restores tried to grant some permissions on SCH1, they
both had to update SCH1's pg_namespace row (specifically nspacl).
We have no support for concurrent updates in the catalog-manipulation
code, so if the second run arrives at that step before the first
one has committed its pg_namespace change, you get this error.

Hi Tom, and al.

I have a related question, on role-to-role grants this time.

Above, it was contention on pg_namespace.nspacl in two transactions.

But during those "restore" transactions, I must also make role-to-role grants,
which AFAIK involve adding rows to pg_auth_members. So they are not subject
to the same "no support for concurrent updates in the catalog-manipulation"
you mentioned, as schema-to-role grants are, right? Because that's an insert,
not an update? Just want to make sure, as I'm thinking how to change our code.

Thanks, --DD

pgsql-general by date:

Previous
From: Marcelo Fernandes
Date:
Subject: Default Value Retention After Dropping Default
Next
From: Dominique Devienne
Date:
Subject: Keep specialized query pairs, or use single more general but more complex one