Getting rid of "tuple concurrently updated" elog()s with concurrent DDLs (at least ALTER TABLE)

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Postgres hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Getting rid of "tuple concurrently updated" elog()s with concurrent DDLs (at least ALTER TABLE)
Date: 2017-12-26 04:55:03
Message-ID: 20171226045503.GA17182@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

Triggering "tuple concurrently updated" from heapam.c, which is an elog(),
is not that difficult for some DDL commands. For example with ALTER ROLE,
just create a role:
psql --no-psqlrc -c 'create role popo'

And then run that in two sessions and the error will show up, triggered
from CatalogTupleUpdate():
while true; do psql --no-psqlrc -c "alter role popo password 'foo'"; done

In this case, upgrading the lock taken on pg_authid from RowExclusiveLock
to ShareRowExclusiveLock prevents concurrent sessions to update each other,
which is what the patch attached does.

I think that we should get rid of all those errors, for many applications
doing concurrent DDLs getting this error is surprising, and could be thought
as a corrupted instance. I am just touching the tip of the iceberg here, as
I have the gut feeling that there are other objects where it is possible to
trigger the failure, and an analysis effort is going to be costly. So I'd
like to get first the temperature about such analysis.

So, opinions?
--
Michael

Attachment Content-Type Size
alter-role-concurrent-v1.patch text/plain 1.3 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2017-12-26 05:31:02 Deadlock in multiple CIC.
Previous Message Masahiko Sawada 2017-12-26 03:28:38 Re: AS OF queries