| From: | Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com> |
|---|---|
| To: | Daniel Farina <daniel(at)heroku(dot)com> |
| Cc: | Nikhil Sontakke <nikkhils(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Concurrent CREATE TABLE/DROP SCHEMA leaves inconsistent leftovers |
| Date: | 2011-11-11 06:04:09 |
| Message-ID: | CABamaqPf=pMPp0ZJ-kfq3F6hTvth48juFhNepFr1g6K1DysqBQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2011-11-11 06:10:59 | Re: Dash in Extension Names |
| Previous Message | Itagaki Takahiro | 2011-11-11 05:45:08 | Re: Dash in Extension Names |