Re: CIC and deadlocks
| От | Pavan Deolasee |
|---|---|
| Тема | Re: CIC and deadlocks |
| Дата | |
| Msg-id | 2e78013d0703310922k31f3c91fyaac7de0947f8362f@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: CIC and deadlocks (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: CIC and deadlocks
|
| Список | pgsql-hackers |
On 3/31/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.
Not sure what you are referring to. But I shall keep this in mind.
Thanks,
Pavan
-- "Pavan Deolasee" <pavan.deolasee@gmail.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
В списке pgsql-hackers по дате отправления: