Re: deadlock while doing VACUUM and DROP

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl>, "Postgres - Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: deadlock while doing VACUUM and DROP
Date: 2008-05-16 14:35:05
Message-ID: 16849.1210948505@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
>> Alternatively, we can just acquire AccessExclusiveLock on the main relation
>> before proceeding with the recursive deletion. That would solve this case,
>> but may be there are other similar deadlocks waiting to happen.

> Surely we should be locking the relation before even doing the dependency scan

Yeah. I think this is just another manifestation of the problem I was
noodling about a few days ago:
http://archives.postgresql.org/pgsql-hackers/2008-05/msg00301.php

As I said then, I don't want to think about it until after commitfest.
I foresee an invasive and not sanely back-patchable patch.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-05-16 14:59:08 Re: libpq object hooks
Previous Message Tom Lane 2008-05-16 14:26:28 Re: Arbitary file size limit in twophase.c