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

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

Responses

Browse pgsql-hackers by date

  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