Re: CREATE EXTENSION BLOCKS

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "David E(dot) Wheeler *EXTERN*" <david(at)justatheory(dot)com>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CREATE EXTENSION BLOCKS
Date: 2013-04-03 09:37:46
Message-ID: A737B7A37273E048B164557ADEF4A58B057D7DEC@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message roadrunner6 2013-04-03 10:09:44 Re: Extra security measures for next week's releases
Previous Message Andres Freund 2013-04-03 09:31:21 Re: regression test failed when enabling checksum