Re: TransactionIdIsInProgress() cache

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: TransactionIdIsInProgress() cache
Дата
Msg-id 47D6901B.7020408@enterprisedb.com
обсуждение исходный текст
Ответ на Re: TransactionIdIsInProgress() cache  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: TransactionIdIsInProgress() cache  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-patches
Alvaro Herrera wrote:
> I didn't check whether your transformation is correct, but if so then it
> can be changed like this and save the extra XidDidCommit call:
>
>     xvac_committed = TransactionIdDidCommit(xvac);
>     if (xvac_committed)
>     {
>         /* committed */
>     }
>     else if (!TransactionIdIsInProgress(xvac))
>     {
>        if (xvac_committed)
>        {
>           /* committed */
>        }
>        else
>        {
>           /* aborted */
>        }
>     }
>     else
>     {
>         /* in-progress */
>     }

Nope, that's not good. Per comments in tqual.c, you have to call
TransactionIdIsInProgress *before* TransactionIdDidCommit, to avoid this
race condition:

1. Xact A inserts a record
2. Xact B does TransactionIdDidCommit, which retuns false because it's
still in progress
3. Xact B commits
4. Xact B does TransactionIdIsInProgress to see if A is still in
progress. It returns false. We conclude that A aborted, while it
actually committed.

My proposal was basically to add an extra TransactionIdDidCommit call
before the TransactionIdIsInProgress call, in the hope that it returns
true and we can skip the rest.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Следующее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: [PERFORM] Very slow (2 tuples/second) sequentialscan after bulk insert; speed returns to ~500 tuples/second aftercommit