Re: CREATE EXTENSION BLOCKS - Mailing list pgsql-hackers

From Albe Laurenz
Subject Re: CREATE EXTENSION BLOCKS
Date
Msg-id A737B7A37273E048B164557ADEF4A58B057D7DEC@ntex2010i.host.magwien.gv.at
Whole thread Raw
In response to CREATE EXTENSION BLOCKS  ("David E. Wheeler" <david@justatheory.com>)
Responses Re: CREATE EXTENSION BLOCKS
List pgsql-hackers
David E. Wheeler wrote:
> I am working on scripts to copy data from Oracle via oracle_fdw. They each do something like this:
>
>     CREATE SCHEMA migrate_stuff;
>     SET search_path TO migrate_stuff,public;
>     CREATE EXTENSION oracle_fdw SCHEMA migrate_rules;
>
[...]
>
> Then I run them in parallel:
>
>     for file in migrate*.sql; do
>         psql -d foo -f $file &
>     done
>     wait
>
> This works fine except for one thing: the first CREATE EXTENSION statement blocks all the others. Even
> when I create the extension in separate schemas in each script! I have to remove the CREATE EXTENSION
> statement, create it in public before any of the scripts run, then drop it when they're done. I'm okay
> with this workaround, but wasn't sure if the blocking of CREATE EXTENSION was intentional or a known
> issue (id did not see it documented in http://www.postgresql.org/docs/current/static/sql-
> createextension.html).

I'd expect one of the CREATE EXTENSION commands to succeed
and the others to block until the transaction is committed,
then to fail with 'extension "oracle_fdw" already exists'.

If that is what happens, it's what I'd expect since
extension names are unique (see the unique constraint on
pg_extension).

Yours,
Laurenz Albe



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: regression test failed when enabling checksum
Next
From: roadrunner6@gmx.at
Date:
Subject: Re: Extra security measures for next week's releases