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
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 |