From: | "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CIC and deadlocks |
Date: | 2007-03-31 16:22:23 |
Message-ID: | 2e78013d0703310922k31f3c91fyaac7de0947f8362f@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On 3/31/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> > Isn't CREATE INDEX CONCURRENTLY prone deadlock conditions ?
>
> 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
deadlock!
Lazy VACUUM is safe because we don't include "inVacuum" transactions
in the snapshot and hence don't wait for it in CIC. I haven't checked, but
VACUUM FULL would also deadlock.
> I think you may be describing a missed opportunity in that logic,
> more than a reason to add still another fragile assumption for HOT.
Not sure what you are referring to. But I shall keep this in mind.
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Luke Lonergan | 2007-03-31 17:06:26 | Re: Oracle indemnifies PostgreSQL on its patents |
Previous Message | Joshua D. Drake | 2007-03-31 16:14:08 | Re: Feature thought: idle in transaction timeout |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-03-31 17:33:15 | Re: CIC and deadlocks |
Previous Message | Magnus Hagander | 2007-03-31 15:55:45 | Re: COPY-able sql log outputs |