Concurrent CREATE USER MAPPING and DROP SERVER
Hello.
I think I may have found a bug in the CREATE USER MAPPING / DROP SERVER
handling.
It is possible to create a user mapping on a server and drop said server in
two concurrent transactions, and have both succeed.
This results in an orphan row in the pg_user_mapping table.
I would expect one of those transactions to fail.
This is more easily explained with the following example:
CREATE extension postgres_fdw;
CREATE server pg_server FOREIGN DATA WRAPPER postgres_fdw
-- SESSION 1
BEGIN;
CREATE USER MAPPING FOR postgres SERVER pg_server OPTIONS (user 'user');
-- SESSION 2
BEGIN;
DROP SERVER pg_server;
-- SESSION 1
COMMIT;
-- SESSION 2
COMMIT;
select umserver, s.oid from pg_user_mapping left join pg_foreign_server s on
s.oid = pg_user_mapping.umserver;
┌──────────┬─────┐
│ umserver │ oid │
├──────────┼─────┤
│62172 │ ¤ │
└──────────┴─────┘
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Ronan Dunklau <rdunklau@gmail.com> writes:
It is possible to create a user mapping on a server and drop said server in
two concurrent transactions, and have both succeed.
There are lots of hazards of this sort, since we generally don't try to
lock database objects other than tables when doing DDL. I can't get
particularly excited about this one compared to the rest. We could try
to extend the table-locking protocols to apply to all object types ...
but from here, the amount of work and complexity involved seems far out
of proportion to the benefit.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs