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
