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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
