pg_dump: schema with OID XXXXX does not exist - was Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers - Mailing list pgsql-hackers

From Nikhil Sontakke
Subject pg_dump: schema with OID XXXXX does not exist - was Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Date
Msg-id CANgU5ZcfF82nwzjTiov8S2=_H_kTS_qQ0YH09ep3bneRY7yiAQ@mail.gmail.com
Whole thread Raw
Responses Re: pg_dump: schema with OID XXXXX does not exist - was Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
List 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

pgsql-hackers by date:

Previous
From: "Tomas Vondra"
Date:
Subject: Re: proposal : backend startup hook / after logon trigger
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Allow substitute allocators for PGresult.