From: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kevin Grittner <kgrittn(at)gmail(dot)com>, Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Transactional-DDL DROP/CREATE TABLE |
Date: | 2016-10-10 10:31:58 |
Message-ID: | CAEzk6fcqs4=k0oiAdMCQj8aW0obB4QLQQ8Gj97+Q8QfZnrJ=Kg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 6 October 2016 at 18:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm a bit confused about exactly what the context is here. AFAICS,
> the fragment you quoted should work as you expect, as long as the
> table always exists beforehand. Then, the DROPs serialize the
> transactions' access to the table and all is well. On the other hand,
> if the table *doesn't* exist beforehand, there is nothing to serialize
> on and the behavior Adrian exhibited is what I'd expect.
I accept that this is how things are. I'm just surprised that "DROP
TABLE IF EXISTS" doesn't do the exists-test at commit time, rather
than effectively being "DROP TABLE IF
EXISTED-AT-SOME-RANDOM-POINT-IN-THE-PAST".
At the end of the day this isn't a massive deal - I can simply add
exception code around the failure, as Francisco suggested, or add
oplocks around the code (as per Kevin), or (I suppose) I could do an
individual transaction to CREATE TABLE IF NOT EXISTS as a separate
transaction before I start; it's just something that caught me out
because I didn't expect it to be a problem.
Geoff
From | Date | Subject | |
---|---|---|---|
Next Message | Moreno Andreo | 2016-10-10 11:50:35 | How pg_dump works |
Previous Message | Geoff Winkless | 2016-10-10 10:24:48 | Re: Transactional-DDL DROP/CREATE TABLE |