From: | Nikhil Sontakke <nikkhils(at)gmail(dot)com> |
---|---|
To: | |
Cc: | Daniel Farina <daniel(at)heroku(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | pg_dump: schema with OID XXXXX does not exist - was Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers |
Date: | 2011-11-11 07:57:32 |
Message-ID: | CANgU5ZcfF82nwzjTiov8S2=_H_kTS_qQ0YH09ep3bneRY7yiAQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
> But if it's deemed to be a
> problem, I want to see a solution that's actually watertight.)
>
>
After Daniel's hunch about pg_dump barfing due to such leftover entries
proving out to be true, we have one credible explanation (there might be
other reasons too) for this long standing issue. I see some reports from as
early as 2004 and some as latest as Feb, 2011!
http://archives.postgresql.org/pgsql-bugs/2011-02/msg00185.php
One way in 9.x could be to modify get_object_address to additionally accept
objoid as an argument and use that to lock the schema in AccessShareLock
mode from all places where schema based objects (tables, views, types,
sequences, functions, indexes, extensions, constraints, operators stuff, ts
stuff, rules, domains, etc. phew!) can be created. Or since this is schema
specific, we can as well right a new function to do this. We might also add
logic to only lock user created schemas.
This can be added right after the namespace for the involved object has
been correctly identified. The lock can then get released later as part of
the transaction commit.
Regards,
Nikhils
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2011-11-11 09:18:43 | Allow substitute allocators for PGresult. |
Previous Message | Tomas Vondra | 2011-11-11 07:49:10 | Re: proposal : backend startup hook / after logon trigger |