Re: Insufficient locking for ALTER DEFAULT PRIVILEGES

Alvaro Herrera wrote:

> So it turns out we don't have any locking here at all. I don't believe
> we have it for all object types, but in most cases it's not as obnoxious
> as this one. But at least for relations we have some nice coding in
> RangeVarGetRelidExtended and RangeVarGetAndCheckCreationNamespace that
> protect things.

Now that I actually check with a non-relation object, I see pretty much
the same error. So probably if instead of some narrow bug fix what we
need is some general solution for all object types. I know this has
been discussed a number of times ... Anyway I see now that we should
not consider this a backpatchable bug fix, and I'm not doing the coding
either, at least not now.

Session 1:

alvherre=# begin;
BEGIN
alvherre=# create or replace function f() returns int language plpgsql strict as $$ begin return 2; end; $$;
CREATE FUNCTION

Session 2:
alvherre=# create or replace function f() returns int language plpgsql strict as $$ begin return 3; end; $$;
<blocks>

Session 1:

alvherre=# commit;
COMMIT

Session 2:
ERROR: tuple concurrently updated

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services