Geoff Winkless <pgsqlad...@geoff.dj> writes:
> On 6 October 2016 at 16:47, Kevin Grittner <kgri...@gmail.com> wrote:
>> I recommend using a transactional advisory lock to serialize these.
> Thanks Kevin, that does seem like the best (although not particularly
> pleasant) solution.
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[1]. 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. (It's a bit
unfortunate that the complaint is about a duplicate type name not
a duplicate relation name: that's an artifact of the order in which
the rows are stored into the catalogs, and maybe we should try to
change it, because it's confusing. But one way or the other you're
going to get a unique-index failure in whichever transaction is slightly
behind.)
But if all your transactions are doing this and only this to the table,
then there should never be an instant where the table doesn't exist.
Is there more DDL going on that you have not shown us?
regards, tom lane
[1] at least, since PG 9.2 or thereabouts.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
