Re: deadlock while doing VACUUM and DROP

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