Re: deadlock while doing VACUUM and DROP

On Fri, May 16, 2008 at 1:17 PM, Gregory Stark <stark(at)enterprisedb(dot)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