On Fri, May 16, 2008 at 1:17 PM, Gregory Stark <[EMAIL PROTECTED]> wrote: > > > Surely we should be locking the relation before even doing the dependency scan > or else someone else can come along and add more dependencies after we've > started the scan? >
Yeah, that's indeed possible. I could make that happen the following way: Session 1: - CREATE TABLE test (a int); - Attach the session to gdb - Put a break at dependency.c:727 (just before doDeletion() call) - DROP TABLE test; Session 2: - CREATE INDEX testindx ON test(a); The CREATE INDEX in session 2 succeeds. But DROP TABLE at this point has already scanned all the dependencies and fails to recognize the newly added dependency. As a result, the table gets dropped but the index remains. Session 1: - continue from the breakpoint - DROP TABLE succeeds. - But the index remains postgres=# SELECT relname, relfilenode from pg_class WHERE relname like '%test%'; relname | relfilenode -----------+------------- testindx | 16391 (1 row) You can't even drop the index now. postgres=# DROP INDEX testindx; ERROR: could not open relation with OID 16388 If I remember correctly, we had seen a similar bug report few days back. May be we now know the cause. >> Also I am not sure if the issue is big enough to demand the change. > > I think it is, effectively what we have now is "your DDL could fail randomly > for reasons that are out of your control" :( > Yeah. I think we better fix this, especially given the above mentioned scenario. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
