Re: In progress INSERT wrecks plans on table

От: Tom Lane
Тема: Re: In progress INSERT wrecks plans on table
Дата: ,
Msg-id: 21750.1371401995@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: In progress INSERT wrecks plans on table  (Heikki Linnakangas)
Список: pgsql-performance

Скрыть дерево обсуждения

In progress INSERT wrecks plans on table  (Mark Kirkwood, )
 Re: In progress INSERT wrecks plans on table  (Mark Kirkwood, )
 Re: In progress INSERT wrecks plans on table  (Mark Kirkwood, )
  Re: In progress INSERT wrecks plans on table  (Tom Lane, )
   Re: In progress INSERT wrecks plans on table  (Mark Kirkwood, )
    Re: In progress INSERT wrecks plans on table  (Simon Riggs, )
     Re: In progress INSERT wrecks plans on table  (, )
      Re: In progress INSERT wrecks plans on table  (Thomas Kellerer, )
       Re: In progress INSERT wrecks plans on table  (, )
      Re: In progress INSERT wrecks plans on table  (Simon Riggs, )
       Re: In progress INSERT wrecks plans on table  (Simon Riggs, )
        Re: In progress INSERT wrecks plans on table  (Mark Kirkwood, )
         Re: In progress INSERT wrecks plans on table  (Simon Riggs, )
          Re: In progress INSERT wrecks plans on table  (Matt Clarkson, )
          Re: In progress INSERT wrecks plans on table  (, )
           Re: In progress INSERT wrecks plans on table  (Simon Riggs, )
            Re: In progress INSERT wrecks plans on table  (Mark Kirkwood, )
             Re: In progress INSERT wrecks plans on table  (Matt Clarkson, )
             Re: In progress INSERT wrecks plans on table  (Simon Riggs, )
              Re: In progress INSERT wrecks plans on table  (Mark Kirkwood, )
             Re: In progress INSERT wrecks plans on table  (Vitalii Tymchyshyn, )
              Re: In progress INSERT wrecks plans on table  (Mark Kirkwood, )
               Re: In progress INSERT wrecks plans on table  (Tom Lane, )
                Re: In progress INSERT wrecks plans on table  (Mark Kirkwood, )
          Re: In progress INSERT wrecks plans on table  (Jeff Janes, )
           Re: In progress INSERT wrecks plans on table  (Ants Aasma, )
         Re: In progress INSERT wrecks plans on table  (Heikki Linnakangas, )
          Re: In progress INSERT wrecks plans on table  (Tom Lane, )
          Re: In progress INSERT wrecks plans on table  (Simon Riggs, )
          Re: In progress INSERT wrecks plans on table  (Jeff Janes, )
       Re: In progress INSERT wrecks plans on table  (Heikki Linnakangas, )
        Re: In progress INSERT wrecks plans on table  (Simon Riggs, )
     Re: In progress INSERT wrecks plans on table  (Gavin Flower, )

Heikki Linnakangas <> writes:
> I'm not sure if this the same idea as (3) above, but ISTM that
> HeapTupleSatisfiesMVCC doesn't actually need to call
> TransactionIdIsInProgress(), because it checks XidInMVCCSnapshot(). The
> comment at the top of tqual.c says:

>> * NOTE: must check TransactionIdIsInProgress (which looks in PGXACT array)
>> * before TransactionIdDidCommit/TransactionIdDidAbort (which look in
>> * pg_clog).  Otherwise we have a race condition: we might decide that a
>> * just-committed transaction crashed, because none of the tests succeed.
>> * xact.c is careful to record commit/abort in pg_clog before it unsets
>> * MyPgXact->xid in PGXACT array.  That fixes that problem, but it also
>> * means there is a window where TransactionIdIsInProgress and
>> * TransactionIdDidCommit will both return true.  If we check only
>> * TransactionIdDidCommit, we could consider a tuple committed when a
>> * later GetSnapshotData call will still think the originating transaction
>> * is in progress, which leads to application-level inconsistency.    The
>> * upshot is that we gotta check TransactionIdIsInProgress first in all
>> * code paths, except for a few cases where we are looking at
>> * subtransactions of our own main transaction and so there can't be any
>> * race condition.

> If TransactionIdIsInProgress() returns true for a given XID, then surely
> it was also running when the snapshot was taken (or had not even began
> yet). In which case the XidInMVCCSnapshot() call will also return true.
> Am I missing something?

Yes, you're failing to understand the nature of the race condition.
What we're concerned about is that if tqual says a tuple is committed,
its transaction must be committed (not still in progress) according to
any *subsequently taken* snapshot.  This is not about the contents of
the snapshot we're currently consulting; it's about not wanting a tuple
to be thought committed if anyone could possibly later decide its
transaction is still in progress.

It's possible that this issue would be moot if the only use of
transaction-in-progress data were in tqual.c (so that we could assume
all later tests use the same logic you propose here), but I doubt that
that's true.

            regards, tom lane



В списке pgsql-performance по дате сообщения:

От: Simon Riggs
Дата:
Сообщение: Re: In progress INSERT wrecks plans on table
От: Sameer Thakur
Дата:
Сообщение: pg_stat_statements query normalization