Geoff Winkless <pgsqladmin@xxxxxxxx> writes: > On 6 October 2016 at 16:47, Kevin Grittner <kgrittn@xxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
