mirror of
https://github.com/postgres/postgres.git
synced 2025-07-21 16:02:15 +03:00
pgindent run for release 9.3
This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
This commit is contained in:
Bruce Momjian
@ -120,32 +120,34 @@ static bool ConditionalMultiXactIdWait(MultiXactId multi,
|
||||
static const struct
|
||||
{
|
||||
LOCKMODE hwlock;
|
||||
MultiXactStatus lockstatus;
|
||||
MultiXactStatus updstatus;
|
||||
MultiXactStatus lockstatus;
|
||||
MultiXactStatus updstatus;
|
||||
}
|
||||
tupleLockExtraInfo[MaxLockTupleMode + 1] =
|
||||
|
||||
tupleLockExtraInfo[MaxLockTupleMode + 1] =
|
||||
{
|
||||
{ /* LockTupleKeyShare */
|
||||
{ /* LockTupleKeyShare */
|
||||
AccessShareLock,
|
||||
MultiXactStatusForKeyShare,
|
||||
-1 /* KeyShare does not allow updating tuples */
|
||||
-1 /* KeyShare does not allow updating tuples */
|
||||
},
|
||||
{ /* LockTupleShare */
|
||||
{ /* LockTupleShare */
|
||||
RowShareLock,
|
||||
MultiXactStatusForShare,
|
||||
-1 /* Share does not allow updating tuples */
|
||||
-1 /* Share does not allow updating tuples */
|
||||
},
|
||||
{ /* LockTupleNoKeyExclusive */
|
||||
{ /* LockTupleNoKeyExclusive */
|
||||
ExclusiveLock,
|
||||
MultiXactStatusForNoKeyUpdate,
|
||||
MultiXactStatusNoKeyUpdate
|
||||
},
|
||||
{ /* LockTupleExclusive */
|
||||
{ /* LockTupleExclusive */
|
||||
AccessExclusiveLock,
|
||||
MultiXactStatusForUpdate,
|
||||
MultiXactStatusUpdate
|
||||
}
|
||||
};
|
||||
|
||||
/* Get the LOCKMODE for a given MultiXactStatus */
|
||||
#define LOCKMODE_from_mxstatus(status) \
|
||||
(tupleLockExtraInfo[TUPLOCK_from_mxstatus((status))].hwlock)
|
||||
@ -168,12 +170,12 @@ tupleLockExtraInfo[MaxLockTupleMode + 1] =
|
||||
*/
|
||||
static const int MultiXactStatusLock[MaxMultiXactStatus + 1] =
|
||||
{
|
||||
LockTupleKeyShare, /* ForKeyShare */
|
||||
LockTupleShare, /* ForShare */
|
||||
LockTupleNoKeyExclusive, /* ForNoKeyUpdate */
|
||||
LockTupleExclusive, /* ForUpdate */
|
||||
LockTupleNoKeyExclusive, /* NoKeyUpdate */
|
||||
LockTupleExclusive /* Update */
|
||||
LockTupleKeyShare, /* ForKeyShare */
|
||||
LockTupleShare, /* ForShare */
|
||||
LockTupleNoKeyExclusive, /* ForNoKeyUpdate */
|
||||
LockTupleExclusive, /* ForUpdate */
|
||||
LockTupleNoKeyExclusive, /* NoKeyUpdate */
|
||||
LockTupleExclusive /* Update */
|
||||
};
|
||||
|
||||
/* Get the LockTupleMode for a given MultiXactStatus */
|
||||
@ -365,10 +367,10 @@ heapgetpage(HeapScanDesc scan, BlockNumber page)
|
||||
* page. That's how index-only scans work fine in hot standby. A crucial
|
||||
* difference between index-only scans and heap scans is that the
|
||||
* index-only scan completely relies on the visibility map where as heap
|
||||
* scan looks at the page-level PD_ALL_VISIBLE flag. We are not sure if the
|
||||
* page-level flag can be trusted in the same way, because it might get
|
||||
* propagated somehow without being explicitly WAL-logged, e.g. via a full
|
||||
* page write. Until we can prove that beyond doubt, let's check each
|
||||
* scan looks at the page-level PD_ALL_VISIBLE flag. We are not sure if
|
||||
* the page-level flag can be trusted in the same way, because it might
|
||||
* get propagated somehow without being explicitly WAL-logged, e.g. via a
|
||||
* full page write. Until we can prove that beyond doubt, let's check each
|
||||
* tuple for visibility the hard way.
|
||||
*/
|
||||
all_visible = PageIsAllVisible(dp) && !snapshot->takenDuringRecovery;
|
||||
@ -1880,7 +1882,7 @@ heap_get_latest_tid(Relation relation,
|
||||
* tuple. Check for XMIN match.
|
||||
*/
|
||||
if (TransactionIdIsValid(priorXmax) &&
|
||||
!TransactionIdEquals(priorXmax, HeapTupleHeaderGetXmin(tp.t_data)))
|
||||
!TransactionIdEquals(priorXmax, HeapTupleHeaderGetXmin(tp.t_data)))
|
||||
{
|
||||
UnlockReleaseBuffer(buffer);
|
||||
break;
|
||||
@ -2488,7 +2490,7 @@ compute_infobits(uint16 infomask, uint16 infomask2)
|
||||
((infomask & HEAP_XMAX_IS_MULTI) != 0 ? XLHL_XMAX_IS_MULTI : 0) |
|
||||
((infomask & HEAP_XMAX_LOCK_ONLY) != 0 ? XLHL_XMAX_LOCK_ONLY : 0) |
|
||||
((infomask & HEAP_XMAX_EXCL_LOCK) != 0 ? XLHL_XMAX_EXCL_LOCK : 0) |
|
||||
/* note we ignore HEAP_XMAX_SHR_LOCK here */
|
||||
/* note we ignore HEAP_XMAX_SHR_LOCK here */
|
||||
((infomask & HEAP_XMAX_KEYSHR_LOCK) != 0 ? XLHL_XMAX_KEYSHR_LOCK : 0) |
|
||||
((infomask2 & HEAP_KEYS_UPDATED) != 0 ?
|
||||
XLHL_KEYS_UPDATED : 0);
|
||||
@ -2730,13 +2732,12 @@ l1:
|
||||
}
|
||||
|
||||
/*
|
||||
* If this is the first possibly-multixact-able operation in the
|
||||
* current transaction, set my per-backend OldestMemberMXactId setting.
|
||||
* We can be certain that the transaction will never become a member of
|
||||
* any older MultiXactIds than that. (We have to do this even if we
|
||||
* end up just using our own TransactionId below, since some other
|
||||
* backend could incorporate our XID into a MultiXact immediately
|
||||
* afterwards.)
|
||||
* If this is the first possibly-multixact-able operation in the current
|
||||
* transaction, set my per-backend OldestMemberMXactId setting. We can be
|
||||
* certain that the transaction will never become a member of any older
|
||||
* MultiXactIds than that. (We have to do this even if we end up just
|
||||
* using our own TransactionId below, since some other backend could
|
||||
* incorporate our XID into a MultiXact immediately afterwards.)
|
||||
*/
|
||||
MultiXactIdSetOldestMember();
|
||||
|
||||
@ -2846,7 +2847,7 @@ simple_heap_delete(Relation relation, ItemPointer tid)
|
||||
|
||||
result = heap_delete(relation, tid,
|
||||
GetCurrentCommandId(true), InvalidSnapshot,
|
||||
true /* wait for commit */,
|
||||
true /* wait for commit */ ,
|
||||
&hufd);
|
||||
switch (result)
|
||||
{
|
||||
@ -2936,7 +2937,7 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
|
||||
bool checked_lockers;
|
||||
bool locker_remains;
|
||||
TransactionId xmax_new_tuple,
|
||||
xmax_old_tuple;
|
||||
xmax_old_tuple;
|
||||
uint16 infomask_old_tuple,
|
||||
infomask2_old_tuple,
|
||||
infomask_new_tuple,
|
||||
@ -3006,13 +3007,13 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
|
||||
|
||||
/*
|
||||
* If we're not updating any "key" column, we can grab a weaker lock type.
|
||||
* This allows for more concurrency when we are running simultaneously with
|
||||
* foreign key checks.
|
||||
* This allows for more concurrency when we are running simultaneously
|
||||
* with foreign key checks.
|
||||
*
|
||||
* Note that if a column gets detoasted while executing the update, but the
|
||||
* value ends up being the same, this test will fail and we will use the
|
||||
* stronger lock. This is acceptable; the important case to optimize is
|
||||
* updates that don't manipulate key columns, not those that
|
||||
* Note that if a column gets detoasted while executing the update, but
|
||||
* the value ends up being the same, this test will fail and we will use
|
||||
* the stronger lock. This is acceptable; the important case to optimize
|
||||
* is updates that don't manipulate key columns, not those that
|
||||
* serendipitiously arrive at the same key values.
|
||||
*/
|
||||
HeapSatisfiesHOTandKeyUpdate(relation, hot_attrs, key_attrs,
|
||||
@ -3026,12 +3027,12 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup,
|
||||
|
||||
/*
|
||||
* If this is the first possibly-multixact-able operation in the
|
||||
* current transaction, set my per-backend OldestMemberMXactId setting.
|
||||
* We can be certain that the transaction will never become a member of
|
||||
* any older MultiXactIds than that. (We have to do this even if we
|
||||
* end up just using our own TransactionId below, since some other
|
||||
* backend could incorporate our XID into a MultiXact immediately
|
||||
* afterwards.)
|
||||
* current transaction, set my per-backend OldestMemberMXactId
|
||||
* setting. We can be certain that the transaction will never become a
|
||||
* member of any older MultiXactIds than that. (We have to do this
|
||||
* even if we end up just using our own TransactionId below, since
|
||||
* some other backend could incorporate our XID into a MultiXact
|
||||
* immediately afterwards.)
|
||||
*/
|
||||
MultiXactIdSetOldestMember();
|
||||
}
|
||||
@ -3064,7 +3065,7 @@ l2:
|
||||
}
|
||||
else if (result == HeapTupleBeingUpdated && wait)
|
||||
{
|
||||
TransactionId xwait;
|
||||
TransactionId xwait;
|
||||
uint16 infomask;
|
||||
bool can_continue = false;
|
||||
|
||||
@ -3073,13 +3074,14 @@ l2:
|
||||
/*
|
||||
* XXX note that we don't consider the "no wait" case here. This
|
||||
* isn't a problem currently because no caller uses that case, but it
|
||||
* should be fixed if such a caller is introduced. It wasn't a problem
|
||||
* previously because this code would always wait, but now that some
|
||||
* tuple locks do not conflict with one of the lock modes we use, it is
|
||||
* possible that this case is interesting to handle specially.
|
||||
* should be fixed if such a caller is introduced. It wasn't a
|
||||
* problem previously because this code would always wait, but now
|
||||
* that some tuple locks do not conflict with one of the lock modes we
|
||||
* use, it is possible that this case is interesting to handle
|
||||
* specially.
|
||||
*
|
||||
* This may cause failures with third-party code that calls heap_update
|
||||
* directly.
|
||||
* This may cause failures with third-party code that calls
|
||||
* heap_update directly.
|
||||
*/
|
||||
|
||||
/* must copy state data before unlocking buffer */
|
||||
@ -3109,15 +3111,15 @@ l2:
|
||||
* gone (or even not sleep at all in some cases); we need to preserve
|
||||
* it as locker, unless it is gone completely.
|
||||
*
|
||||
* If it's not a multi, we need to check for sleeping conditions before
|
||||
* actually going to sleep. If the update doesn't conflict with the
|
||||
* locks, we just continue without sleeping (but making sure it is
|
||||
* preserved).
|
||||
* If it's not a multi, we need to check for sleeping conditions
|
||||
* before actually going to sleep. If the update doesn't conflict
|
||||
* with the locks, we just continue without sleeping (but making sure
|
||||
* it is preserved).
|
||||
*/
|
||||
if (infomask & HEAP_XMAX_IS_MULTI)
|
||||
{
|
||||
TransactionId update_xact;
|
||||
int remain;
|
||||
TransactionId update_xact;
|
||||
int remain;
|
||||
|
||||
/* wait for multixact */
|
||||
MultiXactIdWait((MultiXactId) xwait, mxact_status, &remain,
|
||||
@ -3135,18 +3137,18 @@ l2:
|
||||
goto l2;
|
||||
|
||||
/*
|
||||
* Note that the multixact may not be done by now. It could have
|
||||
* Note that the multixact may not be done by now. It could have
|
||||
* surviving members; our own xact or other subxacts of this
|
||||
* backend, and also any other concurrent transaction that locked
|
||||
* the tuple with KeyShare if we only got TupleLockUpdate. If this
|
||||
* is the case, we have to be careful to mark the updated tuple
|
||||
* with the surviving members in Xmax.
|
||||
* the tuple with KeyShare if we only got TupleLockUpdate. If
|
||||
* this is the case, we have to be careful to mark the updated
|
||||
* tuple with the surviving members in Xmax.
|
||||
*
|
||||
* Note that there could have been another update in the MultiXact.
|
||||
* In that case, we need to check whether it committed or aborted.
|
||||
* If it aborted we are safe to update it again; otherwise there is
|
||||
* an update conflict, and we have to return HeapTupleUpdated
|
||||
* below.
|
||||
* Note that there could have been another update in the
|
||||
* MultiXact. In that case, we need to check whether it committed
|
||||
* or aborted. If it aborted we are safe to update it again;
|
||||
* otherwise there is an update conflict, and we have to return
|
||||
* HeapTupleUpdated below.
|
||||
*
|
||||
* In the LockTupleExclusive case, we still need to preserve the
|
||||
* surviving members: those would include the tuple locks we had
|
||||
@ -3167,21 +3169,21 @@ l2:
|
||||
else
|
||||
{
|
||||
/*
|
||||
* If it's just a key-share locker, and we're not changing the
|
||||
* key columns, we don't need to wait for it to end; but we
|
||||
* need to preserve it as locker.
|
||||
* If it's just a key-share locker, and we're not changing the key
|
||||
* columns, we don't need to wait for it to end; but we need to
|
||||
* preserve it as locker.
|
||||
*/
|
||||
if (HEAP_XMAX_IS_KEYSHR_LOCKED(infomask) && key_intact)
|
||||
{
|
||||
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
|
||||
|
||||
/*
|
||||
* recheck the locker; if someone else changed the tuple while we
|
||||
* weren't looking, start over.
|
||||
* recheck the locker; if someone else changed the tuple while
|
||||
* we weren't looking, start over.
|
||||
*/
|
||||
if ((oldtup.t_data->t_infomask & HEAP_XMAX_IS_MULTI) ||
|
||||
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(oldtup.t_data),
|
||||
xwait))
|
||||
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(oldtup.t_data),
|
||||
xwait))
|
||||
goto l2;
|
||||
|
||||
can_continue = true;
|
||||
@ -3194,13 +3196,13 @@ l2:
|
||||
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
|
||||
|
||||
/*
|
||||
* xwait is done, but if xwait had just locked the tuple then some
|
||||
* other xact could update this tuple before we get to this point.
|
||||
* Check for xmax change, and start over if so.
|
||||
* xwait is done, but if xwait had just locked the tuple then
|
||||
* some other xact could update this tuple before we get to
|
||||
* this point. Check for xmax change, and start over if so.
|
||||
*/
|
||||
if ((oldtup.t_data->t_infomask & HEAP_XMAX_IS_MULTI) ||
|
||||
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(oldtup.t_data),
|
||||
xwait))
|
||||
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(oldtup.t_data),
|
||||
xwait))
|
||||
goto l2;
|
||||
|
||||
/* Otherwise check if it committed or aborted */
|
||||
@ -3247,8 +3249,8 @@ l2:
|
||||
* visible while we were busy locking the buffer, or during some
|
||||
* subsequent window during which we had it unlocked, we'll have to unlock
|
||||
* and re-lock, to avoid holding the buffer lock across an I/O. That's a
|
||||
* bit unfortunate, especially since we'll now have to recheck whether
|
||||
* the tuple has been locked or updated under us, but hopefully it won't
|
||||
* bit unfortunate, especially since we'll now have to recheck whether the
|
||||
* tuple has been locked or updated under us, but hopefully it won't
|
||||
* happen very often.
|
||||
*/
|
||||
if (vmbuffer == InvalidBuffer && PageIsAllVisible(page))
|
||||
@ -3656,9 +3658,9 @@ heap_tuple_attr_equals(TupleDesc tupdesc, int attrnum,
|
||||
|
||||
/*
|
||||
* Extract the corresponding values. XXX this is pretty inefficient if
|
||||
* there are many indexed columns. Should HeapSatisfiesHOTandKeyUpdate do a
|
||||
* single heap_deform_tuple call on each tuple, instead? But that doesn't
|
||||
* work for system columns ...
|
||||
* there are many indexed columns. Should HeapSatisfiesHOTandKeyUpdate do
|
||||
* a single heap_deform_tuple call on each tuple, instead? But that
|
||||
* doesn't work for system columns ...
|
||||
*/
|
||||
value1 = heap_getattr(tup1, attrnum, tupdesc, &isnull1);
|
||||
value2 = heap_getattr(tup2, attrnum, tupdesc, &isnull2);
|
||||
@ -3720,12 +3722,12 @@ HeapSatisfiesHOTandKeyUpdate(Relation relation,
|
||||
bool *satisfies_hot, bool *satisfies_key,
|
||||
HeapTuple oldtup, HeapTuple newtup)
|
||||
{
|
||||
int next_hot_attnum;
|
||||
int next_key_attnum;
|
||||
bool hot_result = true;
|
||||
bool key_result = true;
|
||||
bool key_done = false;
|
||||
bool hot_done = false;
|
||||
int next_hot_attnum;
|
||||
int next_key_attnum;
|
||||
bool hot_result = true;
|
||||
bool key_result = true;
|
||||
bool key_done = false;
|
||||
bool hot_done = false;
|
||||
|
||||
next_hot_attnum = bms_first_member(hot_attrs);
|
||||
if (next_hot_attnum == -1)
|
||||
@ -3743,8 +3745,8 @@ HeapSatisfiesHOTandKeyUpdate(Relation relation,
|
||||
|
||||
for (;;)
|
||||
{
|
||||
int check_now;
|
||||
bool changed;
|
||||
int check_now;
|
||||
bool changed;
|
||||
|
||||
/* both bitmapsets are now empty */
|
||||
if (key_done && hot_done)
|
||||
@ -3813,7 +3815,7 @@ simple_heap_update(Relation relation, ItemPointer otid, HeapTuple tup)
|
||||
|
||||
result = heap_update(relation, otid, tup,
|
||||
GetCurrentCommandId(true), InvalidSnapshot,
|
||||
true /* wait for commit */,
|
||||
true /* wait for commit */ ,
|
||||
&hufd, &lockmode);
|
||||
switch (result)
|
||||
{
|
||||
@ -3843,7 +3845,7 @@ simple_heap_update(Relation relation, ItemPointer otid, HeapTuple tup)
|
||||
static MultiXactStatus
|
||||
get_mxact_status_for_lock(LockTupleMode mode, bool is_update)
|
||||
{
|
||||
MultiXactStatus retval;
|
||||
MultiXactStatus retval;
|
||||
|
||||
if (is_update)
|
||||
retval = tupleLockExtraInfo[mode].updstatus;
|
||||
@ -3933,7 +3935,7 @@ l3:
|
||||
uint16 infomask;
|
||||
uint16 infomask2;
|
||||
bool require_sleep;
|
||||
ItemPointerData t_ctid;
|
||||
ItemPointerData t_ctid;
|
||||
|
||||
/* must copy state data before unlocking buffer */
|
||||
xwait = HeapTupleHeaderGetRawXmax(tuple->t_data);
|
||||
@ -3944,22 +3946,22 @@ l3:
|
||||
LockBuffer(*buffer, BUFFER_LOCK_UNLOCK);
|
||||
|
||||
/*
|
||||
* If any subtransaction of the current top transaction already holds a
|
||||
* lock as strong or stronger than what we're requesting, we
|
||||
* If any subtransaction of the current top transaction already holds
|
||||
* a lock as strong or stronger than what we're requesting, we
|
||||
* effectively hold the desired lock already. We *must* succeed
|
||||
* without trying to take the tuple lock, else we will deadlock against
|
||||
* anyone wanting to acquire a stronger lock.
|
||||
* without trying to take the tuple lock, else we will deadlock
|
||||
* against anyone wanting to acquire a stronger lock.
|
||||
*/
|
||||
if (infomask & HEAP_XMAX_IS_MULTI)
|
||||
{
|
||||
int i;
|
||||
int nmembers;
|
||||
int i;
|
||||
int nmembers;
|
||||
MultiXactMember *members;
|
||||
|
||||
/*
|
||||
* We don't need to allow old multixacts here; if that had been the
|
||||
* case, HeapTupleSatisfiesUpdate would have returned MayBeUpdated
|
||||
* and we wouldn't be here.
|
||||
* We don't need to allow old multixacts here; if that had been
|
||||
* the case, HeapTupleSatisfiesUpdate would have returned
|
||||
* MayBeUpdated and we wouldn't be here.
|
||||
*/
|
||||
nmembers = GetMultiXactIdMembers(xwait, &members, false);
|
||||
|
||||
@ -3967,7 +3969,7 @@ l3:
|
||||
{
|
||||
if (TransactionIdIsCurrentTransactionId(members[i].xid))
|
||||
{
|
||||
LockTupleMode membermode;
|
||||
LockTupleMode membermode;
|
||||
|
||||
membermode = TUPLOCK_from_mxstatus(members[i].status);
|
||||
|
||||
@ -4001,8 +4003,8 @@ l3:
|
||||
if (!ConditionalLockTupleTuplock(relation, tid, mode))
|
||||
ereport(ERROR,
|
||||
(errcode(ERRCODE_LOCK_NOT_AVAILABLE),
|
||||
errmsg("could not obtain lock on row in relation \"%s\"",
|
||||
RelationGetRelationName(relation))));
|
||||
errmsg("could not obtain lock on row in relation \"%s\"",
|
||||
RelationGetRelationName(relation))));
|
||||
}
|
||||
else
|
||||
LockTupleTuplock(relation, tid, mode);
|
||||
@ -4023,34 +4025,34 @@ l3:
|
||||
* continue if the key hasn't been modified.
|
||||
*
|
||||
* However, if there are updates, we need to walk the update chain
|
||||
* to mark future versions of the row as locked, too. That way, if
|
||||
* somebody deletes that future version, we're protected against
|
||||
* the key going away. This locking of future versions could block
|
||||
* momentarily, if a concurrent transaction is deleting a key; or
|
||||
* it could return a value to the effect that the transaction
|
||||
* deleting the key has already committed. So we do this before
|
||||
* re-locking the buffer; otherwise this would be prone to
|
||||
* deadlocks.
|
||||
* to mark future versions of the row as locked, too. That way,
|
||||
* if somebody deletes that future version, we're protected
|
||||
* against the key going away. This locking of future versions
|
||||
* could block momentarily, if a concurrent transaction is
|
||||
* deleting a key; or it could return a value to the effect that
|
||||
* the transaction deleting the key has already committed. So we
|
||||
* do this before re-locking the buffer; otherwise this would be
|
||||
* prone to deadlocks.
|
||||
*
|
||||
* Note that the TID we're locking was grabbed before we unlocked
|
||||
* the buffer. For it to change while we're not looking, the other
|
||||
* properties we're testing for below after re-locking the buffer
|
||||
* would also change, in which case we would restart this loop
|
||||
* above.
|
||||
* the buffer. For it to change while we're not looking, the
|
||||
* other properties we're testing for below after re-locking the
|
||||
* buffer would also change, in which case we would restart this
|
||||
* loop above.
|
||||
*/
|
||||
if (!(infomask2 & HEAP_KEYS_UPDATED))
|
||||
{
|
||||
bool updated;
|
||||
bool updated;
|
||||
|
||||
updated = !HEAP_XMAX_IS_LOCKED_ONLY(infomask);
|
||||
|
||||
/*
|
||||
* If there are updates, follow the update chain; bail out
|
||||
* if that cannot be done.
|
||||
* If there are updates, follow the update chain; bail out if
|
||||
* that cannot be done.
|
||||
*/
|
||||
if (follow_updates && updated)
|
||||
{
|
||||
HTSU_Result res;
|
||||
HTSU_Result res;
|
||||
|
||||
res = heap_lock_updated_tuple(relation, tuple, &t_ctid,
|
||||
GetCurrentTransactionId(),
|
||||
@ -4069,8 +4071,9 @@ l3:
|
||||
/*
|
||||
* Make sure it's still an appropriate lock, else start over.
|
||||
* Also, if it wasn't updated before we released the lock, but
|
||||
* is updated now, we start over too; the reason is that we now
|
||||
* need to follow the update chain to lock the new versions.
|
||||
* is updated now, we start over too; the reason is that we
|
||||
* now need to follow the update chain to lock the new
|
||||
* versions.
|
||||
*/
|
||||
if (!HeapTupleHeaderIsOnlyLocked(tuple->t_data) &&
|
||||
((tuple->t_data->t_infomask2 & HEAP_KEYS_UPDATED) ||
|
||||
@ -4114,20 +4117,20 @@ l3:
|
||||
{
|
||||
/*
|
||||
* If we're requesting NoKeyExclusive, we might also be able to
|
||||
* avoid sleeping; just ensure that there's no other lock type than
|
||||
* KeyShare. Note that this is a bit more involved than just
|
||||
* avoid sleeping; just ensure that there's no other lock type
|
||||
* than KeyShare. Note that this is a bit more involved than just
|
||||
* checking hint bits -- we need to expand the multixact to figure
|
||||
* out lock modes for each one (unless there was only one such
|
||||
* locker).
|
||||
*/
|
||||
if (infomask & HEAP_XMAX_IS_MULTI)
|
||||
{
|
||||
int nmembers;
|
||||
int nmembers;
|
||||
MultiXactMember *members;
|
||||
|
||||
/*
|
||||
* We don't need to allow old multixacts here; if that had been
|
||||
* the case, HeapTupleSatisfiesUpdate would have returned
|
||||
* We don't need to allow old multixacts here; if that had
|
||||
* been the case, HeapTupleSatisfiesUpdate would have returned
|
||||
* MayBeUpdated and we wouldn't be here.
|
||||
*/
|
||||
nmembers = GetMultiXactIdMembers(xwait, &members, false);
|
||||
@ -4135,15 +4138,15 @@ l3:
|
||||
if (nmembers <= 0)
|
||||
{
|
||||
/*
|
||||
* No need to keep the previous xmax here. This is unlikely
|
||||
* to happen.
|
||||
* No need to keep the previous xmax here. This is
|
||||
* unlikely to happen.
|
||||
*/
|
||||
require_sleep = false;
|
||||
}
|
||||
else
|
||||
{
|
||||
int i;
|
||||
bool allowed = true;
|
||||
int i;
|
||||
bool allowed = true;
|
||||
|
||||
for (i = 0; i < nmembers; i++)
|
||||
{
|
||||
@ -4180,8 +4183,8 @@ l3:
|
||||
|
||||
/* if the xmax changed in the meantime, start over */
|
||||
if ((tuple->t_data->t_infomask & HEAP_XMAX_IS_MULTI) ||
|
||||
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(tuple->t_data),
|
||||
xwait))
|
||||
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(tuple->t_data),
|
||||
xwait))
|
||||
goto l3;
|
||||
/* otherwise, we're good */
|
||||
require_sleep = false;
|
||||
@ -4221,7 +4224,7 @@ l3:
|
||||
if (follow_updates &&
|
||||
!HEAP_XMAX_IS_LOCKED_ONLY(infomask))
|
||||
{
|
||||
HTSU_Result res;
|
||||
HTSU_Result res;
|
||||
|
||||
res = heap_lock_updated_tuple(relation, tuple, &t_ctid,
|
||||
GetCurrentTransactionId(),
|
||||
@ -4243,15 +4246,15 @@ l3:
|
||||
* for xmax change, and start over if so.
|
||||
*/
|
||||
if (!(tuple->t_data->t_infomask & HEAP_XMAX_IS_MULTI) ||
|
||||
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(tuple->t_data),
|
||||
xwait))
|
||||
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(tuple->t_data),
|
||||
xwait))
|
||||
goto l3;
|
||||
|
||||
/*
|
||||
* Of course, the multixact might not be done here: if we're
|
||||
* requesting a light lock mode, other transactions with light
|
||||
* locks could still be alive, as well as locks owned by our
|
||||
* own xact or other subxacts of this backend. We need to
|
||||
* own xact or other subxacts of this backend. We need to
|
||||
* preserve the surviving MultiXact members. Note that it
|
||||
* isn't absolutely necessary in the latter case, but doing so
|
||||
* is simpler.
|
||||
@ -4275,7 +4278,7 @@ l3:
|
||||
if (follow_updates &&
|
||||
!HEAP_XMAX_IS_LOCKED_ONLY(infomask))
|
||||
{
|
||||
HTSU_Result res;
|
||||
HTSU_Result res;
|
||||
|
||||
res = heap_lock_updated_tuple(relation, tuple, &t_ctid,
|
||||
GetCurrentTransactionId(),
|
||||
@ -4294,15 +4297,15 @@ l3:
|
||||
/*
|
||||
* xwait is done, but if xwait had just locked the tuple then
|
||||
* some other xact could update this tuple before we get to
|
||||
* this point. Check for xmax change, and start over if so.
|
||||
* this point. Check for xmax change, and start over if so.
|
||||
*/
|
||||
if ((tuple->t_data->t_infomask & HEAP_XMAX_IS_MULTI) ||
|
||||
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(tuple->t_data),
|
||||
xwait))
|
||||
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(tuple->t_data),
|
||||
xwait))
|
||||
goto l3;
|
||||
|
||||
/*
|
||||
* Otherwise check if it committed or aborted. Note we cannot
|
||||
* Otherwise check if it committed or aborted. Note we cannot
|
||||
* be here if the tuple was only locked by somebody who didn't
|
||||
* conflict with us; that should have been handled above. So
|
||||
* that transaction must necessarily be gone by now.
|
||||
@ -4355,8 +4358,8 @@ failed:
|
||||
* for cases where it is a plain TransactionId.
|
||||
*
|
||||
* Note in particular that this covers the case where we already hold
|
||||
* exclusive lock on the tuple and the caller only wants key share or share
|
||||
* lock. It would certainly not do to give up the exclusive lock.
|
||||
* exclusive lock on the tuple and the caller only wants key share or
|
||||
* share lock. It would certainly not do to give up the exclusive lock.
|
||||
*/
|
||||
if (!(old_infomask & (HEAP_XMAX_INVALID |
|
||||
HEAP_XMAX_COMMITTED |
|
||||
@ -4379,13 +4382,12 @@ failed:
|
||||
}
|
||||
|
||||
/*
|
||||
* If this is the first possibly-multixact-able operation in the
|
||||
* current transaction, set my per-backend OldestMemberMXactId setting.
|
||||
* We can be certain that the transaction will never become a member of
|
||||
* any older MultiXactIds than that. (We have to do this even if we
|
||||
* end up just using our own TransactionId below, since some other
|
||||
* backend could incorporate our XID into a MultiXact immediately
|
||||
* afterwards.)
|
||||
* If this is the first possibly-multixact-able operation in the current
|
||||
* transaction, set my per-backend OldestMemberMXactId setting. We can be
|
||||
* certain that the transaction will never become a member of any older
|
||||
* MultiXactIds than that. (We have to do this even if we end up just
|
||||
* using our own TransactionId below, since some other backend could
|
||||
* incorporate our XID into a MultiXact immediately afterwards.)
|
||||
*/
|
||||
MultiXactIdSetOldestMember();
|
||||
|
||||
@ -4419,11 +4421,11 @@ failed:
|
||||
HeapTupleHeaderSetXmax(tuple->t_data, xid);
|
||||
|
||||
/*
|
||||
* Make sure there is no forward chain link in t_ctid. Note that in the
|
||||
* Make sure there is no forward chain link in t_ctid. Note that in the
|
||||
* cases where the tuple has been updated, we must not overwrite t_ctid,
|
||||
* because it was set by the updater. Moreover, if the tuple has been
|
||||
* updated, we need to follow the update chain to lock the new versions
|
||||
* of the tuple as well.
|
||||
* updated, we need to follow the update chain to lock the new versions of
|
||||
* the tuple as well.
|
||||
*/
|
||||
if (HEAP_XMAX_IS_LOCKED_ONLY(new_infomask))
|
||||
tuple->t_data->t_ctid = *tid;
|
||||
@ -4514,9 +4516,9 @@ compute_new_xmax_infomask(TransactionId xmax, uint16 old_infomask,
|
||||
TransactionId *result_xmax, uint16 *result_infomask,
|
||||
uint16 *result_infomask2)
|
||||
{
|
||||
TransactionId new_xmax;
|
||||
uint16 new_infomask,
|
||||
new_infomask2;
|
||||
TransactionId new_xmax;
|
||||
uint16 new_infomask,
|
||||
new_infomask2;
|
||||
|
||||
l5:
|
||||
new_infomask = 0;
|
||||
@ -4562,11 +4564,11 @@ l5:
|
||||
}
|
||||
else if (old_infomask & HEAP_XMAX_IS_MULTI)
|
||||
{
|
||||
MultiXactStatus new_status;
|
||||
MultiXactStatus new_status;
|
||||
|
||||
/*
|
||||
* Currently we don't allow XMAX_COMMITTED to be set for multis,
|
||||
* so cross-check.
|
||||
* Currently we don't allow XMAX_COMMITTED to be set for multis, so
|
||||
* cross-check.
|
||||
*/
|
||||
Assert(!(old_infomask & HEAP_XMAX_COMMITTED));
|
||||
|
||||
@ -4587,10 +4589,11 @@ l5:
|
||||
|
||||
/*
|
||||
* If the XMAX is already a MultiXactId, then we need to expand it to
|
||||
* include add_to_xmax; but if all the members were lockers and are all
|
||||
* gone, we can do away with the IS_MULTI bit and just set add_to_xmax
|
||||
* as the only locker/updater. If all lockers are gone and we have an
|
||||
* updater that aborted, we can also do without a multi.
|
||||
* include add_to_xmax; but if all the members were lockers and are
|
||||
* all gone, we can do away with the IS_MULTI bit and just set
|
||||
* add_to_xmax as the only locker/updater. If all lockers are gone
|
||||
* and we have an updater that aborted, we can also do without a
|
||||
* multi.
|
||||
*
|
||||
* The cost of doing GetMultiXactIdMembers would be paid by
|
||||
* MultiXactIdExpand if we weren't to do this, so this check is not
|
||||
@ -4624,8 +4627,8 @@ l5:
|
||||
* It's a committed update, so we need to preserve him as updater of
|
||||
* the tuple.
|
||||
*/
|
||||
MultiXactStatus status;
|
||||
MultiXactStatus new_status;
|
||||
MultiXactStatus status;
|
||||
MultiXactStatus new_status;
|
||||
|
||||
if (old_infomask2 & HEAP_KEYS_UPDATED)
|
||||
status = MultiXactStatusUpdate;
|
||||
@ -4633,6 +4636,7 @@ l5:
|
||||
status = MultiXactStatusNoKeyUpdate;
|
||||
|
||||
new_status = get_mxact_status_for_lock(mode, is_update);
|
||||
|
||||
/*
|
||||
* since it's not running, it's obviously impossible for the old
|
||||
* updater to be identical to the current one, so we need not check
|
||||
@ -4648,8 +4652,8 @@ l5:
|
||||
* create a new MultiXactId that includes both the old locker or
|
||||
* updater and our own TransactionId.
|
||||
*/
|
||||
MultiXactStatus status;
|
||||
MultiXactStatus new_status;
|
||||
MultiXactStatus status;
|
||||
MultiXactStatus new_status;
|
||||
|
||||
if (HEAP_XMAX_IS_LOCKED_ONLY(old_infomask))
|
||||
{
|
||||
@ -4668,8 +4672,8 @@ l5:
|
||||
{
|
||||
/*
|
||||
* LOCK_ONLY can be present alone only when a page has been
|
||||
* upgraded by pg_upgrade. But in that case,
|
||||
* TransactionIdIsInProgress() should have returned false. We
|
||||
* upgraded by pg_upgrade. But in that case,
|
||||
* TransactionIdIsInProgress() should have returned false. We
|
||||
* assume it's no longer locked in this case.
|
||||
*/
|
||||
elog(WARNING, "LOCK_ONLY found for Xid in progress %u", xmax);
|
||||
@ -4696,8 +4700,8 @@ l5:
|
||||
*/
|
||||
if (xmax == add_to_xmax)
|
||||
{
|
||||
LockTupleMode old_mode = TUPLOCK_from_mxstatus(status);
|
||||
bool old_isupd = ISUPDATE_from_mxstatus(status);
|
||||
LockTupleMode old_mode = TUPLOCK_from_mxstatus(status);
|
||||
bool old_isupd = ISUPDATE_from_mxstatus(status);
|
||||
|
||||
/*
|
||||
* We can do this if the new LockTupleMode is higher or equal than
|
||||
@ -4728,8 +4732,8 @@ l5:
|
||||
* It's a committed update, so we gotta preserve him as updater of the
|
||||
* tuple.
|
||||
*/
|
||||
MultiXactStatus status;
|
||||
MultiXactStatus new_status;
|
||||
MultiXactStatus status;
|
||||
MultiXactStatus new_status;
|
||||
|
||||
if (old_infomask2 & HEAP_KEYS_UPDATED)
|
||||
status = MultiXactStatusUpdate;
|
||||
@ -4737,6 +4741,7 @@ l5:
|
||||
status = MultiXactStatusNoKeyUpdate;
|
||||
|
||||
new_status = get_mxact_status_for_lock(mode, is_update);
|
||||
|
||||
/*
|
||||
* since it's not running, it's obviously impossible for the old
|
||||
* updater to be identical to the current one, so we need not check
|
||||
@ -4774,14 +4779,14 @@ static HTSU_Result
|
||||
heap_lock_updated_tuple_rec(Relation rel, ItemPointer tid, TransactionId xid,
|
||||
LockTupleMode mode)
|
||||
{
|
||||
ItemPointerData tupid;
|
||||
HeapTupleData mytup;
|
||||
Buffer buf;
|
||||
uint16 new_infomask,
|
||||
new_infomask2,
|
||||
old_infomask;
|
||||
TransactionId xmax,
|
||||
new_xmax;
|
||||
ItemPointerData tupid;
|
||||
HeapTupleData mytup;
|
||||
Buffer buf;
|
||||
uint16 new_infomask,
|
||||
new_infomask2,
|
||||
old_infomask;
|
||||
TransactionId xmax,
|
||||
new_xmax;
|
||||
|
||||
ItemPointerCopy(tid, &tupid);
|
||||
|
||||
@ -4802,16 +4807,17 @@ l4:
|
||||
xmax = HeapTupleHeaderGetRawXmax(mytup.t_data);
|
||||
|
||||
/*
|
||||
* If this tuple is updated and the key has been modified (or deleted),
|
||||
* what we do depends on the status of the updating transaction: if
|
||||
* it's live, we sleep until it finishes; if it has committed, we have
|
||||
* to fail (i.e. return HeapTupleUpdated); if it aborted, we ignore it.
|
||||
* For updates that didn't touch the key, we can just plough ahead.
|
||||
* If this tuple is updated and the key has been modified (or
|
||||
* deleted), what we do depends on the status of the updating
|
||||
* transaction: if it's live, we sleep until it finishes; if it has
|
||||
* committed, we have to fail (i.e. return HeapTupleUpdated); if it
|
||||
* aborted, we ignore it. For updates that didn't touch the key, we
|
||||
* can just plough ahead.
|
||||
*/
|
||||
if (!(old_infomask & HEAP_XMAX_INVALID) &&
|
||||
(mytup.t_data->t_infomask2 & HEAP_KEYS_UPDATED))
|
||||
{
|
||||
TransactionId update_xid;
|
||||
TransactionId update_xid;
|
||||
|
||||
/*
|
||||
* Note: we *must* check TransactionIdIsInProgress before
|
||||
@ -4832,7 +4838,7 @@ l4:
|
||||
goto l4;
|
||||
}
|
||||
else if (TransactionIdDidAbort(update_xid))
|
||||
; /* okay to proceed */
|
||||
; /* okay to proceed */
|
||||
else if (TransactionIdDidCommit(update_xid))
|
||||
{
|
||||
UnlockReleaseBuffer(buf);
|
||||
@ -4861,7 +4867,7 @@ l4:
|
||||
{
|
||||
xl_heap_lock_updated xlrec;
|
||||
XLogRecPtr recptr;
|
||||
XLogRecData rdata[2];
|
||||
XLogRecData rdata[2];
|
||||
Page page = BufferGetPage(buf);
|
||||
|
||||
xlrec.target.node = rel->rd_node;
|
||||
@ -4889,7 +4895,7 @@ l4:
|
||||
|
||||
/* if we find the end of update chain, we're done. */
|
||||
if (mytup.t_data->t_infomask & HEAP_XMAX_INVALID ||
|
||||
ItemPointerEquals(&mytup.t_self, &mytup.t_data->t_ctid) ||
|
||||
ItemPointerEquals(&mytup.t_self, &mytup.t_data->t_ctid) ||
|
||||
HeapTupleHeaderIsOnlyLocked(mytup.t_data))
|
||||
{
|
||||
UnlockReleaseBuffer(buf);
|
||||
@ -4904,13 +4910,13 @@ l4:
|
||||
|
||||
/*
|
||||
* heap_lock_updated_tuple
|
||||
* Follow update chain when locking an updated tuple, acquiring locks (row
|
||||
* marks) on the updated versions.
|
||||
* Follow update chain when locking an updated tuple, acquiring locks (row
|
||||
* marks) on the updated versions.
|
||||
*
|
||||
* The initial tuple is assumed to be already locked.
|
||||
*
|
||||
* This function doesn't check visibility, it just inconditionally marks the
|
||||
* tuple(s) as locked. If any tuple in the updated chain is being deleted
|
||||
* tuple(s) as locked. If any tuple in the updated chain is being deleted
|
||||
* concurrently (or updated with the key being modified), sleep until the
|
||||
* transaction doing it is finished.
|
||||
*
|
||||
@ -4932,12 +4938,12 @@ heap_lock_updated_tuple(Relation rel, HeapTuple tuple, ItemPointer ctid,
|
||||
{
|
||||
/*
|
||||
* If this is the first possibly-multixact-able operation in the
|
||||
* current transaction, set my per-backend OldestMemberMXactId setting.
|
||||
* We can be certain that the transaction will never become a member of
|
||||
* any older MultiXactIds than that. (We have to do this even if we
|
||||
* end up just using our own TransactionId below, since some other
|
||||
* backend could incorporate our XID into a MultiXact immediately
|
||||
* afterwards.)
|
||||
* current transaction, set my per-backend OldestMemberMXactId
|
||||
* setting. We can be certain that the transaction will never become a
|
||||
* member of any older MultiXactIds than that. (We have to do this
|
||||
* even if we end up just using our own TransactionId below, since
|
||||
* some other backend could incorporate our XID into a MultiXact
|
||||
* immediately afterwards.)
|
||||
*/
|
||||
MultiXactIdSetOldestMember();
|
||||
|
||||
@ -5117,9 +5123,9 @@ heap_freeze_tuple(HeapTupleHeader tuple, TransactionId cutoff_xid,
|
||||
HeapTupleHeaderSetXmax(tuple, InvalidTransactionId);
|
||||
|
||||
/*
|
||||
* The tuple might be marked either XMAX_INVALID or XMAX_COMMITTED
|
||||
* + LOCKED. Normalize to INVALID just to be sure no one gets
|
||||
* confused. Also get rid of the HEAP_KEYS_UPDATED bit.
|
||||
* The tuple might be marked either XMAX_INVALID or XMAX_COMMITTED +
|
||||
* LOCKED. Normalize to INVALID just to be sure no one gets confused.
|
||||
* Also get rid of the HEAP_KEYS_UPDATED bit.
|
||||
*/
|
||||
tuple->t_infomask &= ~HEAP_XMAX_BITS;
|
||||
tuple->t_infomask |= HEAP_XMAX_INVALID;
|
||||
@ -5172,13 +5178,13 @@ static void
|
||||
GetMultiXactIdHintBits(MultiXactId multi, uint16 *new_infomask,
|
||||
uint16 *new_infomask2)
|
||||
{
|
||||
int nmembers;
|
||||
MultiXactMember *members;
|
||||
int i;
|
||||
uint16 bits = HEAP_XMAX_IS_MULTI;
|
||||
uint16 bits2 = 0;
|
||||
bool has_update = false;
|
||||
LockTupleMode strongest = LockTupleKeyShare;
|
||||
int nmembers;
|
||||
MultiXactMember *members;
|
||||
int i;
|
||||
uint16 bits = HEAP_XMAX_IS_MULTI;
|
||||
uint16 bits2 = 0;
|
||||
bool has_update = false;
|
||||
LockTupleMode strongest = LockTupleKeyShare;
|
||||
|
||||
/*
|
||||
* We only use this in multis we just created, so they cannot be values
|
||||
@ -5188,7 +5194,7 @@ GetMultiXactIdHintBits(MultiXactId multi, uint16 *new_infomask,
|
||||
|
||||
for (i = 0; i < nmembers; i++)
|
||||
{
|
||||
LockTupleMode mode;
|
||||
LockTupleMode mode;
|
||||
|
||||
/*
|
||||
* Remember the strongest lock mode held by any member of the
|
||||
@ -5249,22 +5255,22 @@ GetMultiXactIdHintBits(MultiXactId multi, uint16 *new_infomask,
|
||||
static TransactionId
|
||||
MultiXactIdGetUpdateXid(TransactionId xmax, uint16 t_infomask)
|
||||
{
|
||||
TransactionId update_xact = InvalidTransactionId;
|
||||
MultiXactMember *members;
|
||||
int nmembers;
|
||||
TransactionId update_xact = InvalidTransactionId;
|
||||
MultiXactMember *members;
|
||||
int nmembers;
|
||||
|
||||
Assert(!(t_infomask & HEAP_XMAX_LOCK_ONLY));
|
||||
Assert(t_infomask & HEAP_XMAX_IS_MULTI);
|
||||
|
||||
/*
|
||||
* Since we know the LOCK_ONLY bit is not set, this cannot be a
|
||||
* multi from pre-pg_upgrade.
|
||||
* Since we know the LOCK_ONLY bit is not set, this cannot be a multi from
|
||||
* pre-pg_upgrade.
|
||||
*/
|
||||
nmembers = GetMultiXactIdMembers(xmax, &members, false);
|
||||
|
||||
if (nmembers > 0)
|
||||
{
|
||||
int i;
|
||||
int i;
|
||||
|
||||
for (i = 0; i < nmembers; i++)
|
||||
{
|
||||
@ -5284,6 +5290,7 @@ MultiXactIdGetUpdateXid(TransactionId xmax, uint16 t_infomask)
|
||||
members[i].status == MultiXactStatusUpdate);
|
||||
update_xact = members[i].xid;
|
||||
#ifndef USE_ASSERT_CHECKING
|
||||
|
||||
/*
|
||||
* in an assert-enabled build, walk the whole array to ensure
|
||||
* there's no other updater.
|
||||
@ -5300,7 +5307,7 @@ MultiXactIdGetUpdateXid(TransactionId xmax, uint16 t_infomask)
|
||||
|
||||
/*
|
||||
* HeapTupleGetUpdateXid
|
||||
* As above, but use a HeapTupleHeader
|
||||
* As above, but use a HeapTupleHeader
|
||||
*
|
||||
* See also HeapTupleHeaderGetUpdateXid, which can be used without previously
|
||||
* checking the hint bits.
|
||||
@ -5314,7 +5321,7 @@ HeapTupleGetUpdateXid(HeapTupleHeader tuple)
|
||||
|
||||
/*
|
||||
* Do_MultiXactIdWait
|
||||
* Actual implementation for the two functions below.
|
||||
* Actual implementation for the two functions below.
|
||||
*
|
||||
* We do this by sleeping on each member using XactLockTableWait. Any
|
||||
* members that belong to the current backend are *not* waited for, however;
|
||||
@ -5432,7 +5439,7 @@ ConditionalMultiXactIdWait(MultiXactId multi, MultiXactStatus status,
|
||||
* heap_tuple_needs_freeze
|
||||
*
|
||||
* Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac)
|
||||
* are older than the specified cutoff XID or MultiXactId. If so, return TRUE.
|
||||
* are older than the specified cutoff XID or MultiXactId. If so, return TRUE.
|
||||
*
|
||||
* It doesn't matter whether the tuple is alive or dead, we are checking
|
||||
* to see if a tuple needs to be removed or frozen to avoid wraparound.
|
||||
@ -6091,7 +6098,7 @@ heap_xlog_freeze(XLogRecPtr lsn, XLogRecord *record)
|
||||
{
|
||||
xl_heap_freeze *xlrec = (xl_heap_freeze *) XLogRecGetData(record);
|
||||
TransactionId cutoff_xid = xlrec->cutoff_xid;
|
||||
MultiXactId cutoff_multi = xlrec->cutoff_multi;
|
||||
MultiXactId cutoff_multi = xlrec->cutoff_multi;
|
||||
Buffer buffer;
|
||||
Page page;
|
||||
|
||||
@ -6361,7 +6368,7 @@ heap_xlog_delete(XLogRecPtr lsn, XLogRecord *record)
|
||||
return;
|
||||
page = (Page) BufferGetPage(buffer);
|
||||
|
||||
if (lsn <= PageGetLSN(page)) /* changes are applied */
|
||||
if (lsn <= PageGetLSN(page)) /* changes are applied */
|
||||
{
|
||||
UnlockReleaseBuffer(buffer);
|
||||
return;
|
||||
@ -6729,7 +6736,7 @@ heap_xlog_update(XLogRecPtr lsn, XLogRecord *record, bool hot_update)
|
||||
goto newt;
|
||||
page = (Page) BufferGetPage(obuffer);
|
||||
|
||||
if (lsn <= PageGetLSN(page)) /* changes are applied */
|
||||
if (lsn <= PageGetLSN(page)) /* changes are applied */
|
||||
{
|
||||
if (samepage)
|
||||
{
|
||||
@ -6931,7 +6938,7 @@ heap_xlog_lock(XLogRecPtr lsn, XLogRecord *record)
|
||||
return;
|
||||
page = (Page) BufferGetPage(buffer);
|
||||
|
||||
if (lsn <= PageGetLSN(page)) /* changes are applied */
|
||||
if (lsn <= PageGetLSN(page)) /* changes are applied */
|
||||
{
|
||||
UnlockReleaseBuffer(buffer);
|
||||
return;
|
||||
@ -6962,7 +6969,7 @@ static void
|
||||
heap_xlog_lock_updated(XLogRecPtr lsn, XLogRecord *record)
|
||||
{
|
||||
xl_heap_lock_updated *xlrec =
|
||||
(xl_heap_lock_updated *) XLogRecGetData(record);
|
||||
(xl_heap_lock_updated *) XLogRecGetData(record);
|
||||
Buffer buffer;
|
||||
Page page;
|
||||
OffsetNumber offnum;
|
||||
@ -6983,7 +6990,7 @@ heap_xlog_lock_updated(XLogRecPtr lsn, XLogRecord *record)
|
||||
return;
|
||||
page = (Page) BufferGetPage(buffer);
|
||||
|
||||
if (lsn <= PageGetLSN(page)) /* changes are applied */
|
||||
if (lsn <= PageGetLSN(page)) /* changes are applied */
|
||||
{
|
||||
UnlockReleaseBuffer(buffer);
|
||||
return;
|
||||
@ -7033,7 +7040,7 @@ heap_xlog_inplace(XLogRecPtr lsn, XLogRecord *record)
|
||||
return;
|
||||
page = (Page) BufferGetPage(buffer);
|
||||
|
||||
if (lsn <= PageGetLSN(page)) /* changes are applied */
|
||||
if (lsn <= PageGetLSN(page)) /* changes are applied */
|
||||
{
|
||||
UnlockReleaseBuffer(buffer);
|
||||
return;
|
||||
|
||||
Reference in New Issue
Block a user