1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* tqual.c--
|
1997-11-02 16:27:14 +01:00
|
|
|
* POSTGRES "time" qualification code.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
* Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
1997-11-26 04:54:23 +01:00
|
|
|
* $Header: /cvsroot/pgsql/src/backend/utils/time/tqual.c,v 1.13 1997/11/26 03:54:18 momjian Exp $
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* #define TQUALDEBUG 1 */
|
|
|
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include "access/htup.h"
|
|
|
|
#include "access/xact.h"
|
|
|
|
#include "storage/bufmgr.h"
|
|
|
|
#include "access/transam.h"
|
|
|
|
#include "utils/elog.h"
|
|
|
|
#include "utils/palloc.h"
|
|
|
|
#include "utils/tqual.h"
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
extern bool PostgresIsInitialized;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* XXX Transaction system override hacks start here
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#ifndef GOODAMI
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
static TransactionId HeapSpecialTransactionId = InvalidTransactionId;
|
|
|
|
static CommandId HeapSpecialCommandId = FirstCommandId;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
void
|
|
|
|
setheapoverride(bool on)
|
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (on)
|
|
|
|
{
|
|
|
|
TransactionIdStore(GetCurrentTransactionId(),
|
|
|
|
&HeapSpecialTransactionId);
|
|
|
|
HeapSpecialCommandId = GetCurrentCommandId();
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
HeapSpecialTransactionId = InvalidTransactionId;
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-11-26 04:54:23 +01:00
|
|
|
/* static, but called in debug macro */
|
|
|
|
bool
|
1996-07-09 08:22:35 +02:00
|
|
|
heapisoverride()
|
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!TransactionIdIsValid(HeapSpecialTransactionId))
|
|
|
|
{
|
|
|
|
return (false);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!TransactionIdEquals(GetCurrentTransactionId(),
|
|
|
|
HeapSpecialTransactionId) ||
|
|
|
|
GetCurrentCommandId() != HeapSpecialCommandId)
|
|
|
|
{
|
|
|
|
HeapSpecialTransactionId = InvalidTransactionId;
|
|
|
|
|
|
|
|
return (false);
|
|
|
|
}
|
|
|
|
return (true);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
#endif /* !defined(GOODAMI) */
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
|
|
|
* XXX Transaction system override hacks end here
|
|
|
|
*/
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
static bool HeapTupleSatisfiesItself(HeapTuple tuple);
|
|
|
|
static bool HeapTupleSatisfiesNow(HeapTuple tuple);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*
|
1997-11-21 00:24:03 +01:00
|
|
|
* HeapTupleSatisfiesScope --
|
1997-09-07 07:04:48 +02:00
|
|
|
* True iff heap tuple satsifies a time qual.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
* Note:
|
1997-09-07 07:04:48 +02:00
|
|
|
* Assumes heap tuple is valid.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
bool
|
1997-11-21 00:24:03 +01:00
|
|
|
HeapTupleSatisfiesVisibility(HeapTuple tuple, bool seeself)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
if (TransactionIdEquals(tuple->t_xmax, AmiTransactionId))
|
|
|
|
return (false);
|
|
|
|
|
1997-11-21 00:24:03 +01:00
|
|
|
if (seeself == true || heapisoverride())
|
1997-09-07 07:04:48 +02:00
|
|
|
return (HeapTupleSatisfiesItself(tuple));
|
1997-11-21 00:24:03 +01:00
|
|
|
else
|
1997-09-07 07:04:48 +02:00
|
|
|
return (HeapTupleSatisfiesNow(tuple));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* HeapTupleSatisfiesItself --
|
1997-09-07 07:04:48 +02:00
|
|
|
* True iff heap tuple is valid for "itself."
|
|
|
|
* "{it}self" means valid as of everything that's happened
|
|
|
|
* in the current transaction, _including_ the current command.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
* Note:
|
1997-09-07 07:04:48 +02:00
|
|
|
* Assumes heap tuple is valid.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
/*
|
|
|
|
* The satisfaction of "itself" requires the following:
|
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* ((Xmin == my-transaction && the row was updated by the current transaction, and
|
|
|
|
* (Xmax is null it was not deleted
|
|
|
|
* [|| Xmax != my-transaction)]) [or it was deleted by another transaction]
|
1996-07-09 08:22:35 +02:00
|
|
|
* ||
|
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* (Xmin is committed && the row was modified by a committed transaction, and
|
|
|
|
* (Xmax is null || the row has not been deleted, or
|
|
|
|
* (Xmax != my-transaction && the row was deleted by another transaction
|
|
|
|
* Xmax is not committed))) that has not been committed
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-08 04:41:22 +02:00
|
|
|
static bool
|
1996-07-09 08:22:35 +02:00
|
|
|
HeapTupleSatisfiesItself(HeapTuple tuple)
|
|
|
|
{
|
From: Dan McGuirk <mcguirk@indirect.com>
Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com>
To: hackers@hub.org
Subject: [HACKERS] tmin writeback optimization
I was doing some profiling of the backend, and noticed that during a certain
benchmark I was running somewhere between 30% and 75% of the backend's CPU
time was being spent in calls to TransactionIdDidCommit() from
HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that
changed rows' transactions had in fact been committed even though the rows'
tmin values had not yet been set.
When a query looks at a given row, it needs to figure out whether the
transaction that changed the row has been committed and hence it should pay
attention to the row, or whether on the other hand the transaction is still
in progress or has been aborted and hence the row should be ignored. If
a tmin value is set, it is known definitively that the row's transaction
has been committed. However, if tmin is not set, the transaction
referred to in xmin must be looked up in pg_log, and this is what the
backend was spending a lot of time doing during my benchmark.
So, implementing a method suggested by Vadim, I created the following
patch that, the first time a query finds a committed row whose tmin value
is not set, sets it, and marks the buffer where the row is stored as
dirty. (It works for tmax, too.) This doesn't result in the boost in
real time performance I was hoping for, however it does decrease backend
CPU usage by up to two-thirds in certain situations, so it could be
rather beneficial in high-concurrency settings.
1997-03-28 08:06:53 +01:00
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (!(tuple->t_infomask & HEAP_XMIN_COMMITTED))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-11-02 16:27:14 +01:00
|
|
|
if (tuple->t_infomask & HEAP_XMIN_INVALID) /* xid invalid or aborted */
|
|
|
|
return (false);
|
|
|
|
|
|
|
|
if (TransactionIdIsCurrentTransactionId(tuple->t_xmin))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-11-02 16:27:14 +01:00
|
|
|
if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid */
|
|
|
|
return (true);
|
|
|
|
else
|
|
|
|
return (false);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (!TransactionIdDidCommit(tuple->t_xmin))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-11-02 16:27:14 +01:00
|
|
|
if (TransactionIdDidAbort(tuple->t_xmin))
|
|
|
|
tuple->t_infomask |= HEAP_XMIN_INVALID; /* aborted */
|
1997-09-07 07:04:48 +02:00
|
|
|
return (false);
|
|
|
|
}
|
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
tuple->t_infomask |= HEAP_XMIN_COMMITTED;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
/* the tuple was inserted validly */
|
From: Dan McGuirk <mcguirk@indirect.com>
Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com>
To: hackers@hub.org
Subject: [HACKERS] tmin writeback optimization
I was doing some profiling of the backend, and noticed that during a certain
benchmark I was running somewhere between 30% and 75% of the backend's CPU
time was being spent in calls to TransactionIdDidCommit() from
HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that
changed rows' transactions had in fact been committed even though the rows'
tmin values had not yet been set.
When a query looks at a given row, it needs to figure out whether the
transaction that changed the row has been committed and hence it should pay
attention to the row, or whether on the other hand the transaction is still
in progress or has been aborted and hence the row should be ignored. If
a tmin value is set, it is known definitively that the row's transaction
has been committed. However, if tmin is not set, the transaction
referred to in xmin must be looked up in pg_log, and this is what the
backend was spending a lot of time doing during my benchmark.
So, implementing a method suggested by Vadim, I created the following
patch that, the first time a query finds a committed row whose tmin value
is not set, sets it, and marks the buffer where the row is stored as
dirty. (It works for tmax, too.) This doesn't result in the boost in
real time performance I was hoping for, however it does decrease backend
CPU usage by up to two-thirds in certain situations, so it could be
rather beneficial in high-concurrency settings.
1997-03-28 08:06:53 +01:00
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid or aborted */
|
1997-09-07 07:04:48 +02:00
|
|
|
return (true);
|
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (tuple->t_infomask & HEAP_XMAX_COMMITTED)
|
|
|
|
return (false);
|
|
|
|
|
|
|
|
if (TransactionIdIsCurrentTransactionId(tuple->t_xmax))
|
1997-09-07 07:04:48 +02:00
|
|
|
return (false);
|
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (!TransactionIdDidCommit(tuple->t_xmax))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-11-02 16:27:14 +01:00
|
|
|
if (TransactionIdDidAbort(tuple->t_xmax))
|
|
|
|
tuple->t_infomask |= HEAP_XMAX_INVALID; /* aborted */
|
1997-09-07 07:04:48 +02:00
|
|
|
return (true);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* by here, deleting transaction has committed */
|
1997-11-02 16:27:14 +01:00
|
|
|
tuple->t_infomask |= HEAP_XMAX_COMMITTED;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
return (false);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* HeapTupleSatisfiesNow --
|
1997-09-07 07:04:48 +02:00
|
|
|
* True iff heap tuple is valid "now."
|
|
|
|
* "now" means valid including everything that's happened
|
|
|
|
* in the current transaction _up to, but not including,_
|
|
|
|
* the current command.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
* Note:
|
1997-09-07 07:04:48 +02:00
|
|
|
* Assumes heap tuple is valid.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
|
|
|
/*
|
|
|
|
* The satisfaction of "now" requires the following:
|
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* ((Xmin == my-transaction && changed by the current transaction
|
|
|
|
* Cmin != my-command && but not by this command, and
|
|
|
|
* (Xmax is null || the row has not been deleted, or
|
|
|
|
* (Xmax == my-transaction && it was deleted by the current transaction
|
|
|
|
* Cmax != my-command))) but not by this command,
|
|
|
|
* || or
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* (Xmin is committed && the row was modified by a committed transaction, and
|
|
|
|
* (Xmax is null || the row has not been deleted, or
|
|
|
|
* (Xmax == my-transaction && the row is being deleted by this command, or
|
|
|
|
* Cmax == my-command) ||
|
|
|
|
* (Xmax is not committed && the row was deleted by another transaction
|
|
|
|
* Xmax != my-transaction)))) that has not been committed
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-08-29 11:05:25 +02:00
|
|
|
* XXX
|
1997-09-07 07:04:48 +02:00
|
|
|
* CommandId stuff didn't work properly if one used SQL-functions in
|
|
|
|
* UPDATE/INSERT(fromSELECT)/DELETE scans: SQL-funcs call
|
|
|
|
* CommandCounterIncrement and made tuples changed/inserted by
|
|
|
|
* current command visible to command itself (so we had multiple
|
|
|
|
* update of updated tuples, etc). - vadim 08/29/97
|
|
|
|
*
|
|
|
|
* mao says 17 march 1993: the tests in this routine are correct;
|
|
|
|
* if you think they're not, you're wrong, and you should think
|
|
|
|
* about it again. i know, it happened to me. we don't need to
|
|
|
|
* check commit time against the start time of this transaction
|
|
|
|
* because 2ph locking protects us from doing the wrong thing.
|
|
|
|
* if you mess around here, you'll break serializability. the only
|
|
|
|
* problem with this code is that it does the wrong thing for system
|
|
|
|
* catalog updates, because the catalogs aren't subject to 2ph, so
|
|
|
|
* the serializability guarantees we provide don't extend to xacts
|
|
|
|
* that do catalog accesses. this is unfortunate, but not critical.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-08 04:41:22 +02:00
|
|
|
static bool
|
1996-07-09 08:22:35 +02:00
|
|
|
HeapTupleSatisfiesNow(HeapTuple tuple)
|
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
if (AMI_OVERRIDE)
|
|
|
|
return true;
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*
|
1997-09-07 07:04:48 +02:00
|
|
|
* If the transaction system isn't yet initialized, then we assume
|
|
|
|
* that transactions committed. We only look at system catalogs
|
|
|
|
* during startup, so this is less awful than it seems, but it's still
|
|
|
|
* pretty awful.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
From: Dan McGuirk <mcguirk@indirect.com>
Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com>
To: hackers@hub.org
Subject: [HACKERS] tmin writeback optimization
I was doing some profiling of the backend, and noticed that during a certain
benchmark I was running somewhere between 30% and 75% of the backend's CPU
time was being spent in calls to TransactionIdDidCommit() from
HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that
changed rows' transactions had in fact been committed even though the rows'
tmin values had not yet been set.
When a query looks at a given row, it needs to figure out whether the
transaction that changed the row has been committed and hence it should pay
attention to the row, or whether on the other hand the transaction is still
in progress or has been aborted and hence the row should be ignored. If
a tmin value is set, it is known definitively that the row's transaction
has been committed. However, if tmin is not set, the transaction
referred to in xmin must be looked up in pg_log, and this is what the
backend was spending a lot of time doing during my benchmark.
So, implementing a method suggested by Vadim, I created the following
patch that, the first time a query finds a committed row whose tmin value
is not set, sets it, and marks the buffer where the row is stored as
dirty. (It works for tmax, too.) This doesn't result in the boost in
real time performance I was hoping for, however it does decrease backend
CPU usage by up to two-thirds in certain situations, so it could be
rather beneficial in high-concurrency settings.
1997-03-28 08:06:53 +01:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!PostgresIsInitialized)
|
1997-11-02 16:27:14 +01:00
|
|
|
return ((bool) (TransactionIdIsValid(tuple->t_xmin) &&
|
|
|
|
!TransactionIdIsValid(tuple->t_xmax)));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (!(tuple->t_infomask & HEAP_XMIN_COMMITTED))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-11-02 16:27:14 +01:00
|
|
|
if (tuple->t_infomask & HEAP_XMIN_INVALID) /* xid invalid or aborted */
|
1997-09-07 07:04:48 +02:00
|
|
|
return (false);
|
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (TransactionIdIsCurrentTransactionId(tuple->t_xmin))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-11-02 16:27:14 +01:00
|
|
|
if (CommandIdGEScanCommandId(tuple->t_cmin))
|
|
|
|
return (false); /* inserted after scan started */
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid */
|
1997-09-07 07:04:48 +02:00
|
|
|
return (true);
|
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
Assert(TransactionIdIsCurrentTransactionId(tuple->t_xmax));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
if (CommandIdGEScanCommandId(tuple->t_cmax))
|
1997-11-02 16:27:14 +01:00
|
|
|
return (true); /* deleted after scan started */
|
|
|
|
else
|
|
|
|
return (false); /* deleted before scan started */
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* this call is VERY expensive - requires a log table lookup.
|
|
|
|
*/
|
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (!TransactionIdDidCommit(tuple->t_xmin))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-11-02 16:27:14 +01:00
|
|
|
if (TransactionIdDidAbort(tuple->t_xmin))
|
|
|
|
tuple->t_infomask |= HEAP_XMIN_INVALID; /* aborted */
|
1997-09-07 07:04:48 +02:00
|
|
|
return (false);
|
|
|
|
}
|
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
tuple->t_infomask |= HEAP_XMIN_COMMITTED;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
From: Dan McGuirk <mcguirk@indirect.com>
Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com>
To: hackers@hub.org
Subject: [HACKERS] tmin writeback optimization
I was doing some profiling of the backend, and noticed that during a certain
benchmark I was running somewhere between 30% and 75% of the backend's CPU
time was being spent in calls to TransactionIdDidCommit() from
HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that
changed rows' transactions had in fact been committed even though the rows'
tmin values had not yet been set.
When a query looks at a given row, it needs to figure out whether the
transaction that changed the row has been committed and hence it should pay
attention to the row, or whether on the other hand the transaction is still
in progress or has been aborted and hence the row should be ignored. If
a tmin value is set, it is known definitively that the row's transaction
has been committed. However, if tmin is not set, the transaction
referred to in xmin must be looked up in pg_log, and this is what the
backend was spending a lot of time doing during my benchmark.
So, implementing a method suggested by Vadim, I created the following
patch that, the first time a query finds a committed row whose tmin value
is not set, sets it, and marks the buffer where the row is stored as
dirty. (It works for tmax, too.) This doesn't result in the boost in
real time performance I was hoping for, however it does decrease backend
CPU usage by up to two-thirds in certain situations, so it could be
rather beneficial in high-concurrency settings.
1997-03-28 08:06:53 +01:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* by here, the inserting transaction has committed */
|
From: Dan McGuirk <mcguirk@indirect.com>
Reply-To: hackers@hub.org, Dan McGuirk <mcguirk@indirect.com>
To: hackers@hub.org
Subject: [HACKERS] tmin writeback optimization
I was doing some profiling of the backend, and noticed that during a certain
benchmark I was running somewhere between 30% and 75% of the backend's CPU
time was being spent in calls to TransactionIdDidCommit() from
HeapTupleSatisfiesNow() or HeapTupleSatisfiesItself() to determine that
changed rows' transactions had in fact been committed even though the rows'
tmin values had not yet been set.
When a query looks at a given row, it needs to figure out whether the
transaction that changed the row has been committed and hence it should pay
attention to the row, or whether on the other hand the transaction is still
in progress or has been aborted and hence the row should be ignored. If
a tmin value is set, it is known definitively that the row's transaction
has been committed. However, if tmin is not set, the transaction
referred to in xmin must be looked up in pg_log, and this is what the
backend was spending a lot of time doing during my benchmark.
So, implementing a method suggested by Vadim, I created the following
patch that, the first time a query finds a committed row whose tmin value
is not set, sets it, and marks the buffer where the row is stored as
dirty. (It works for tmax, too.) This doesn't result in the boost in
real time performance I was hoping for, however it does decrease backend
CPU usage by up to two-thirds in certain situations, so it could be
rather beneficial in high-concurrency settings.
1997-03-28 08:06:53 +01:00
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid or aborted */
|
1997-09-07 07:04:48 +02:00
|
|
|
return (true);
|
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (tuple->t_infomask & HEAP_XMAX_COMMITTED)
|
1997-09-07 07:04:48 +02:00
|
|
|
return (false);
|
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (TransactionIdIsCurrentTransactionId(tuple->t_xmax))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-11-02 16:27:14 +01:00
|
|
|
if (CommandIdGEScanCommandId(tuple->t_cmax))
|
|
|
|
return (true); /* deleted after scan started */
|
|
|
|
else
|
|
|
|
return (false); /* deleted before scan started */
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
if (!TransactionIdDidCommit(tuple->t_xmax))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-11-02 16:27:14 +01:00
|
|
|
if (TransactionIdDidAbort(tuple->t_xmax))
|
|
|
|
tuple->t_infomask |= HEAP_XMAX_INVALID; /* aborted */
|
1996-07-09 08:22:35 +02:00
|
|
|
return (true);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
/* xmax transaction committed */
|
|
|
|
tuple->t_infomask |= HEAP_XMAX_COMMITTED;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-11-02 16:27:14 +01:00
|
|
|
return (false);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|