Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers - Mailing list pgsql-hackers

From Nikhil Sontakke
Subject Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers
Date
Msg-id CABamaqPf=pMPp0ZJ-kfq3F6hTvth48juFhNepFr1g6K1DysqBQ@mail.gmail.com
Whole thread Raw
In response to Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers  (Daniel Farina <daniel@heroku.com>)
List pgsql-hackers

 
> Continuing in gdb, also completes the creation of c2 table without any
> errors. We are now left with a dangling entry in pg_class along with all the
> corresponding data files in our data directory. The problem becomes worse if
> c2 was created using a TABLESPACE. Now dropping of that tablespace does not
> work at all. Am sure we can come up with myriad such other issues.

Hmm.  Does this break pg_dump?  I have reported a bug whereby dangling
pg_class entries point to a namespace that has since been dropped in
the past (and has been reported many times before that, even).


Sure does! I just tried it and got:
pg_dump: schema with OID 16384 does not exist
 
The bug report is here, whereby I also aggregate other similar bug
reports that have taken place over a very long period of time:

http://archives.postgresql.org/pgsql-bugs/2011-02/msg00185.php


I guess we DO need to pay attention to fix this properly now as there are some reports with 9.x too. And I have just provided a way to reproduce this reliably too.

Regards,
Nikhils

pgsql-hackers by date:

Previous
From: Itagaki Takahiro
Date:
Subject: Re: Dash in Extension Names
Next
From: "David E. Wheeler"
Date:
Subject: Re: Dash in Extension Names