Re: CIC and deadlocks

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: CIC and deadlocks
Дата
Msg-id 8481.1176274361@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: CIC and deadlocks  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Ответы Re: CIC and deadlocks  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Список pgsql-hackers
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> When I looked at the code, it occurred to me that possibly we are
> OK with just taking shared lock on the procarray. That means that
> some other transaction can concurrently set its serializable snapshot
> while we are scanning the procarray. But that should not harm us:
> if we see the snapshot set, we wait for the transaction. A transaction
> which is setting its serializable snapshot NOW, can not see the
> tuples that we did not index, isn't it ?

[ itch... ]  The problem is with time-extended execution of
GetSnapshotData; what happens if the other guy lost the CPU for a good
long time while in the middle of GetSnapshotData?  He might set his
xmin based on info you saw as long gone.

You might be correct that it's safe, but the argument would have to
hinge on the OldestXmin process being unable to commit because of
someone holding shared ProcArrayLock; a point you are definitely not
making above.  (Study the comments in GetSnapshotData for awhile,
also those in xact.c's commit-related code.)

I'm about to head to bed and am certainly in no condition to carry the
proof through.  Have at it ...

            regards, tom lane

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Marko Kreen"
Дата:
Сообщение: Re: [DOCS] uuid type not documented
Следующее
От: ITAGAKI Takahiro
Дата:
Сообщение: Re: Question about SHM_QUEUE