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 |
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 |