Re: CIC and deadlocks

"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> On 3/31/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Can you give a specific example?

> txn1 - CREATE INDEX CONCURRENTLY (takes ShareUpdateExclusiveLock)
> txn2 - VACUUM ANALYZE (waits on ShareUpdateExclusiveLock)
> tnx1 - waits for txn2 to complete in the second phase of CIC

Oh, it's the cleanup wait you're worried about.

> Lazy VACUUM is safe because we don't include "inVacuum"  transactions
> in the snapshot and hence don't wait for it in CIC.

Hmm ... only if it's already set inVacuum true ... there's a window
where it has not.

I wonder whether we could change CIC so that the "reference
snapshot" lists only transactions that are running and have already
determined their serializable snapshot (ie, have set proc->xmin).
Xacts that haven't yet done that can be ignored because they couldn't
possibly see the dead tuples we're worried about, no?

Then we could rearrange the order of operations in vacuum_rel so
that we lock the target rel before we acquire a snapshot.  Then
a vacuum waiting for the CIC cannot cause a deadlock.

Multi-rel CLUSTER could be changed the same way.  I'm not particularly
worried about single-rel CLUSTER, only stuff that would be reasonable
to launch from background maintenance tasks.

[ thinks... ]  Actually, it seems risky to omit xids from the reference
snapshot; that could perhaps screw up the index insertions.  But we
could look in the procArray to see if the xid still exists and has set
an xmin before we actually wait for it.
        regards, tom lane