On Fri, May 16, 2008 at 1:17 PM, Gregory Stark <stark@enterprisedb.com> 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
