120
120
static const struct
123
MultiXactStatus lockstatus;
124
MultiXactStatus updstatus;
123
MultiXactStatus lockstatus;
124
MultiXactStatus updstatus;
126
tupleLockExtraInfo[MaxLockTupleMode + 1] =
127
tupleLockExtraInfo[MaxLockTupleMode + 1] =
128
{ /* LockTupleKeyShare */
129
{ /* LockTupleKeyShare */
130
131
MultiXactStatusForKeyShare,
131
-1 /* KeyShare does not allow updating tuples */
132
-1 /* KeyShare does not allow updating tuples */
133
{ /* LockTupleShare */
134
{ /* LockTupleShare */
135
136
MultiXactStatusForShare,
136
-1 /* Share does not allow updating tuples */
137
-1 /* Share does not allow updating tuples */
138
{ /* LockTupleNoKeyExclusive */
139
{ /* LockTupleNoKeyExclusive */
140
141
MultiXactStatusForNoKeyUpdate,
141
142
MultiXactStatusNoKeyUpdate
143
{ /* LockTupleExclusive */
144
{ /* LockTupleExclusive */
144
145
AccessExclusiveLock,
145
146
MultiXactStatusForUpdate,
146
147
MultiXactStatusUpdate
149
151
/* Get the LOCKMODE for a given MultiXactStatus */
150
152
#define LOCKMODE_from_mxstatus(status) \
151
153
(tupleLockExtraInfo[TUPLOCK_from_mxstatus((status))].hwlock)
169
171
static const int MultiXactStatusLock[MaxMultiXactStatus + 1] =
171
LockTupleKeyShare, /* ForKeyShare */
172
LockTupleShare, /* ForShare */
173
LockTupleNoKeyExclusive, /* ForNoKeyUpdate */
174
LockTupleExclusive, /* ForUpdate */
175
LockTupleNoKeyExclusive, /* NoKeyUpdate */
176
LockTupleExclusive /* Update */
173
LockTupleKeyShare, /* ForKeyShare */
174
LockTupleShare, /* ForShare */
175
LockTupleNoKeyExclusive, /* ForNoKeyUpdate */
176
LockTupleExclusive, /* ForUpdate */
177
LockTupleNoKeyExclusive, /* NoKeyUpdate */
178
LockTupleExclusive /* Update */
179
181
/* Get the LockTupleMode for a given MultiXactStatus */
365
367
* page. That's how index-only scans work fine in hot standby. A crucial
366
368
* difference between index-only scans and heap scans is that the
367
369
* index-only scan completely relies on the visibility map where as heap
368
* scan looks at the page-level PD_ALL_VISIBLE flag. We are not sure if the
369
* page-level flag can be trusted in the same way, because it might get
370
* propagated somehow without being explicitly WAL-logged, e.g. via a full
371
* page write. Until we can prove that beyond doubt, let's check each
370
* scan looks at the page-level PD_ALL_VISIBLE flag. We are not sure if
371
* the page-level flag can be trusted in the same way, because it might
372
* get propagated somehow without being explicitly WAL-logged, e.g. via a
373
* full page write. Until we can prove that beyond doubt, let's check each
372
374
* tuple for visibility the hard way.
374
376
all_visible = PageIsAllVisible(dp) && !snapshot->takenDuringRecovery;
1880
1882
* tuple. Check for XMIN match.
1882
1884
if (TransactionIdIsValid(priorXmax) &&
1883
!TransactionIdEquals(priorXmax, HeapTupleHeaderGetXmin(tp.t_data)))
1885
!TransactionIdEquals(priorXmax, HeapTupleHeaderGetXmin(tp.t_data)))
1885
1887
UnlockReleaseBuffer(buffer);
2488
2490
((infomask & HEAP_XMAX_IS_MULTI) != 0 ? XLHL_XMAX_IS_MULTI : 0) |
2489
2491
((infomask & HEAP_XMAX_LOCK_ONLY) != 0 ? XLHL_XMAX_LOCK_ONLY : 0) |
2490
2492
((infomask & HEAP_XMAX_EXCL_LOCK) != 0 ? XLHL_XMAX_EXCL_LOCK : 0) |
2491
/* note we ignore HEAP_XMAX_SHR_LOCK here */
2493
/* note we ignore HEAP_XMAX_SHR_LOCK here */
2492
2494
((infomask & HEAP_XMAX_KEYSHR_LOCK) != 0 ? XLHL_XMAX_KEYSHR_LOCK : 0) |
2493
2495
((infomask2 & HEAP_KEYS_UPDATED) != 0 ?
2494
2496
XLHL_KEYS_UPDATED : 0);
2733
* If this is the first possibly-multixact-able operation in the
2734
* current transaction, set my per-backend OldestMemberMXactId setting.
2735
* We can be certain that the transaction will never become a member of
2736
* any older MultiXactIds than that. (We have to do this even if we
2737
* end up just using our own TransactionId below, since some other
2738
* backend could incorporate our XID into a MultiXact immediately
2735
* If this is the first possibly-multixact-able operation in the current
2736
* transaction, set my per-backend OldestMemberMXactId setting. We can be
2737
* certain that the transaction will never become a member of any older
2738
* MultiXactIds than that. (We have to do this even if we end up just
2739
* using our own TransactionId below, since some other backend could
2740
* incorporate our XID into a MultiXact immediately afterwards.)
2741
2742
MultiXactIdSetOldestMember();
2847
2848
result = heap_delete(relation, tid,
2848
2849
GetCurrentCommandId(true), InvalidSnapshot,
2849
true /* wait for commit */,
2850
true /* wait for commit */ ,
2851
2852
switch (result)
3008
3009
* If we're not updating any "key" column, we can grab a weaker lock type.
3009
* This allows for more concurrency when we are running simultaneously with
3010
* foreign key checks.
3010
* This allows for more concurrency when we are running simultaneously
3011
* with foreign key checks.
3012
* Note that if a column gets detoasted while executing the update, but the
3013
* value ends up being the same, this test will fail and we will use the
3014
* stronger lock. This is acceptable; the important case to optimize is
3015
* updates that don't manipulate key columns, not those that
3013
* Note that if a column gets detoasted while executing the update, but
3014
* the value ends up being the same, this test will fail and we will use
3015
* the stronger lock. This is acceptable; the important case to optimize
3016
* is updates that don't manipulate key columns, not those that
3016
3017
* serendipitiously arrive at the same key values.
3018
3019
HeapSatisfiesHOTandKeyUpdate(relation, hot_attrs, key_attrs,
3028
3029
* If this is the first possibly-multixact-able operation in the
3029
* current transaction, set my per-backend OldestMemberMXactId setting.
3030
* We can be certain that the transaction will never become a member of
3031
* any older MultiXactIds than that. (We have to do this even if we
3032
* end up just using our own TransactionId below, since some other
3033
* backend could incorporate our XID into a MultiXact immediately
3030
* current transaction, set my per-backend OldestMemberMXactId
3031
* setting. We can be certain that the transaction will never become a
3032
* member of any older MultiXactIds than that. (We have to do this
3033
* even if we end up just using our own TransactionId below, since
3034
* some other backend could incorporate our XID into a MultiXact
3035
* immediately afterwards.)
3036
3037
MultiXactIdSetOldestMember();
3074
3075
* XXX note that we don't consider the "no wait" case here. This
3075
3076
* isn't a problem currently because no caller uses that case, but it
3076
* should be fixed if such a caller is introduced. It wasn't a problem
3077
* previously because this code would always wait, but now that some
3078
* tuple locks do not conflict with one of the lock modes we use, it is
3079
* possible that this case is interesting to handle specially.
3077
* should be fixed if such a caller is introduced. It wasn't a
3078
* problem previously because this code would always wait, but now
3079
* that some tuple locks do not conflict with one of the lock modes we
3080
* use, it is possible that this case is interesting to handle
3081
* This may cause failures with third-party code that calls heap_update
3083
* This may cause failures with third-party code that calls
3084
* heap_update directly.
3085
3087
/* must copy state data before unlocking buffer */
3109
3111
* gone (or even not sleep at all in some cases); we need to preserve
3110
3112
* it as locker, unless it is gone completely.
3112
* If it's not a multi, we need to check for sleeping conditions before
3113
* actually going to sleep. If the update doesn't conflict with the
3114
* locks, we just continue without sleeping (but making sure it is
3114
* If it's not a multi, we need to check for sleeping conditions
3115
* before actually going to sleep. If the update doesn't conflict
3116
* with the locks, we just continue without sleeping (but making sure
3117
3119
if (infomask & HEAP_XMAX_IS_MULTI)
3119
TransactionId update_xact;
3121
TransactionId update_xact;
3122
3124
/* wait for multixact */
3123
3125
MultiXactIdWait((MultiXactId) xwait, mxact_status, &remain,
3138
* Note that the multixact may not be done by now. It could have
3140
* Note that the multixact may not be done by now. It could have
3139
3141
* surviving members; our own xact or other subxacts of this
3140
3142
* backend, and also any other concurrent transaction that locked
3141
* the tuple with KeyShare if we only got TupleLockUpdate. If this
3142
* is the case, we have to be careful to mark the updated tuple
3143
* with the surviving members in Xmax.
3143
* the tuple with KeyShare if we only got TupleLockUpdate. If
3144
* this is the case, we have to be careful to mark the updated
3145
* tuple with the surviving members in Xmax.
3145
* Note that there could have been another update in the MultiXact.
3146
* In that case, we need to check whether it committed or aborted.
3147
* If it aborted we are safe to update it again; otherwise there is
3148
* an update conflict, and we have to return HeapTupleUpdated
3147
* Note that there could have been another update in the
3148
* MultiXact. In that case, we need to check whether it committed
3149
* or aborted. If it aborted we are safe to update it again;
3150
* otherwise there is an update conflict, and we have to return
3151
* HeapTupleUpdated below.
3151
3153
* In the LockTupleExclusive case, we still need to preserve the
3152
3154
* surviving members: those would include the tuple locks we had
3170
* If it's just a key-share locker, and we're not changing the
3171
* key columns, we don't need to wait for it to end; but we
3172
* need to preserve it as locker.
3172
* If it's just a key-share locker, and we're not changing the key
3173
* columns, we don't need to wait for it to end; but we need to
3174
* preserve it as locker.
3174
3176
if (HEAP_XMAX_IS_KEYSHR_LOCKED(infomask) && key_intact)
3176
3178
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
3179
* recheck the locker; if someone else changed the tuple while we
3180
* weren't looking, start over.
3181
* recheck the locker; if someone else changed the tuple while
3182
* we weren't looking, start over.
3182
3184
if ((oldtup.t_data->t_infomask & HEAP_XMAX_IS_MULTI) ||
3183
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(oldtup.t_data),
3185
!TransactionIdEquals(
3186
HeapTupleHeaderGetRawXmax(oldtup.t_data),
3194
3197
LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
3197
* xwait is done, but if xwait had just locked the tuple then some
3198
* other xact could update this tuple before we get to this point.
3199
* Check for xmax change, and start over if so.
3200
* xwait is done, but if xwait had just locked the tuple then
3201
* some other xact could update this tuple before we get to
3202
* this point. Check for xmax change, and start over if so.
3201
3204
if ((oldtup.t_data->t_infomask & HEAP_XMAX_IS_MULTI) ||
3202
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(oldtup.t_data),
3205
!TransactionIdEquals(
3206
HeapTupleHeaderGetRawXmax(oldtup.t_data),
3247
3251
* visible while we were busy locking the buffer, or during some
3248
3252
* subsequent window during which we had it unlocked, we'll have to unlock
3249
3253
* and re-lock, to avoid holding the buffer lock across an I/O. That's a
3250
* bit unfortunate, especially since we'll now have to recheck whether
3251
* the tuple has been locked or updated under us, but hopefully it won't
3254
* bit unfortunate, especially since we'll now have to recheck whether the
3255
* tuple has been locked or updated under us, but hopefully it won't
3252
3256
* happen very often.
3254
3258
if (vmbuffer == InvalidBuffer && PageIsAllVisible(page))
3658
3662
* Extract the corresponding values. XXX this is pretty inefficient if
3659
* there are many indexed columns. Should HeapSatisfiesHOTandKeyUpdate do a
3660
* single heap_deform_tuple call on each tuple, instead? But that doesn't
3661
* work for system columns ...
3663
* there are many indexed columns. Should HeapSatisfiesHOTandKeyUpdate do
3664
* a single heap_deform_tuple call on each tuple, instead? But that
3665
* doesn't work for system columns ...
3663
3667
value1 = heap_getattr(tup1, attrnum, tupdesc, &isnull1);
3664
3668
value2 = heap_getattr(tup2, attrnum, tupdesc, &isnull2);
3720
3724
bool *satisfies_hot, bool *satisfies_key,
3721
3725
HeapTuple oldtup, HeapTuple newtup)
3723
int next_hot_attnum;
3724
int next_key_attnum;
3725
bool hot_result = true;
3726
bool key_result = true;
3727
bool key_done = false;
3728
bool hot_done = false;
3727
int next_hot_attnum;
3728
int next_key_attnum;
3729
bool hot_result = true;
3730
bool key_result = true;
3731
bool key_done = false;
3732
bool hot_done = false;
3730
3734
next_hot_attnum = bms_first_member(hot_attrs);
3731
3735
if (next_hot_attnum == -1)
3814
3818
result = heap_update(relation, otid, tup,
3815
3819
GetCurrentCommandId(true), InvalidSnapshot,
3816
true /* wait for commit */,
3820
true /* wait for commit */ ,
3817
3821
&hufd, &lockmode);
3818
3822
switch (result)
3944
3948
LockBuffer(*buffer, BUFFER_LOCK_UNLOCK);
3947
* If any subtransaction of the current top transaction already holds a
3948
* lock as strong or stronger than what we're requesting, we
3951
* If any subtransaction of the current top transaction already holds
3952
* a lock as strong or stronger than what we're requesting, we
3949
3953
* effectively hold the desired lock already. We *must* succeed
3950
* without trying to take the tuple lock, else we will deadlock against
3951
* anyone wanting to acquire a stronger lock.
3954
* without trying to take the tuple lock, else we will deadlock
3955
* against anyone wanting to acquire a stronger lock.
3953
3957
if (infomask & HEAP_XMAX_IS_MULTI)
3957
3961
MultiXactMember *members;
3960
* We don't need to allow old multixacts here; if that had been the
3961
* case, HeapTupleSatisfiesUpdate would have returned MayBeUpdated
3962
* and we wouldn't be here.
3964
* We don't need to allow old multixacts here; if that had been
3965
* the case, HeapTupleSatisfiesUpdate would have returned
3966
* MayBeUpdated and we wouldn't be here.
3964
3968
nmembers = GetMultiXactIdMembers(xwait, &members, false);
4001
4005
if (!ConditionalLockTupleTuplock(relation, tid, mode))
4003
4007
(errcode(ERRCODE_LOCK_NOT_AVAILABLE),
4004
errmsg("could not obtain lock on row in relation \"%s\"",
4005
RelationGetRelationName(relation))));
4008
errmsg("could not obtain lock on row in relation \"%s\"",
4009
RelationGetRelationName(relation))));
4008
4012
LockTupleTuplock(relation, tid, mode);
4023
4027
* continue if the key hasn't been modified.
4025
4029
* However, if there are updates, we need to walk the update chain
4026
* to mark future versions of the row as locked, too. That way, if
4027
* somebody deletes that future version, we're protected against
4028
* the key going away. This locking of future versions could block
4029
* momentarily, if a concurrent transaction is deleting a key; or
4030
* it could return a value to the effect that the transaction
4031
* deleting the key has already committed. So we do this before
4032
* re-locking the buffer; otherwise this would be prone to
4030
* to mark future versions of the row as locked, too. That way,
4031
* if somebody deletes that future version, we're protected
4032
* against the key going away. This locking of future versions
4033
* could block momentarily, if a concurrent transaction is
4034
* deleting a key; or it could return a value to the effect that
4035
* the transaction deleting the key has already committed. So we
4036
* do this before re-locking the buffer; otherwise this would be
4037
* prone to deadlocks.
4035
4039
* Note that the TID we're locking was grabbed before we unlocked
4036
* the buffer. For it to change while we're not looking, the other
4037
* properties we're testing for below after re-locking the buffer
4038
* would also change, in which case we would restart this loop
4040
* the buffer. For it to change while we're not looking, the
4041
* other properties we're testing for below after re-locking the
4042
* buffer would also change, in which case we would restart this
4041
4045
if (!(infomask2 & HEAP_KEYS_UPDATED))
4045
4049
updated = !HEAP_XMAX_IS_LOCKED_ONLY(infomask);
4048
* If there are updates, follow the update chain; bail out
4049
* if that cannot be done.
4052
* If there are updates, follow the update chain; bail out if
4053
* that cannot be done.
4051
4055
if (follow_updates && updated)
4055
4059
res = heap_lock_updated_tuple(relation, tuple, &t_ctid,
4056
4060
GetCurrentTransactionId(),
4070
4074
* Make sure it's still an appropriate lock, else start over.
4071
4075
* Also, if it wasn't updated before we released the lock, but
4072
* is updated now, we start over too; the reason is that we now
4073
* need to follow the update chain to lock the new versions.
4076
* is updated now, we start over too; the reason is that we
4077
* now need to follow the update chain to lock the new
4075
4080
if (!HeapTupleHeaderIsOnlyLocked(tuple->t_data) &&
4076
4081
((tuple->t_data->t_infomask2 & HEAP_KEYS_UPDATED) ||
4116
4121
* If we're requesting NoKeyExclusive, we might also be able to
4117
* avoid sleeping; just ensure that there's no other lock type than
4118
* KeyShare. Note that this is a bit more involved than just
4122
* avoid sleeping; just ensure that there's no other lock type
4123
* than KeyShare. Note that this is a bit more involved than just
4119
4124
* checking hint bits -- we need to expand the multixact to figure
4120
4125
* out lock modes for each one (unless there was only one such
4123
4128
if (infomask & HEAP_XMAX_IS_MULTI)
4126
4131
MultiXactMember *members;
4129
* We don't need to allow old multixacts here; if that had been
4130
* the case, HeapTupleSatisfiesUpdate would have returned
4134
* We don't need to allow old multixacts here; if that had
4135
* been the case, HeapTupleSatisfiesUpdate would have returned
4131
4136
* MayBeUpdated and we wouldn't be here.
4133
4138
nmembers = GetMultiXactIdMembers(xwait, &members, false);
4181
4186
/* if the xmax changed in the meantime, start over */
4182
4187
if ((tuple->t_data->t_infomask & HEAP_XMAX_IS_MULTI) ||
4183
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(tuple->t_data),
4188
!TransactionIdEquals(
4189
HeapTupleHeaderGetRawXmax(tuple->t_data),
4186
4192
/* otherwise, we're good */
4243
4249
* for xmax change, and start over if so.
4245
4251
if (!(tuple->t_data->t_infomask & HEAP_XMAX_IS_MULTI) ||
4246
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(tuple->t_data),
4252
!TransactionIdEquals(
4253
HeapTupleHeaderGetRawXmax(tuple->t_data),
4251
4258
* Of course, the multixact might not be done here: if we're
4252
4259
* requesting a light lock mode, other transactions with light
4253
4260
* locks could still be alive, as well as locks owned by our
4254
* own xact or other subxacts of this backend. We need to
4261
* own xact or other subxacts of this backend. We need to
4255
4262
* preserve the surviving MultiXact members. Note that it
4256
4263
* isn't absolutely necessary in the latter case, but doing so
4295
4302
* xwait is done, but if xwait had just locked the tuple then
4296
4303
* some other xact could update this tuple before we get to
4297
* this point. Check for xmax change, and start over if so.
4304
* this point. Check for xmax change, and start over if so.
4299
4306
if ((tuple->t_data->t_infomask & HEAP_XMAX_IS_MULTI) ||
4300
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(tuple->t_data),
4307
!TransactionIdEquals(
4308
HeapTupleHeaderGetRawXmax(tuple->t_data),
4305
* Otherwise check if it committed or aborted. Note we cannot
4313
* Otherwise check if it committed or aborted. Note we cannot
4306
4314
* be here if the tuple was only locked by somebody who didn't
4307
4315
* conflict with us; that should have been handled above. So
4308
4316
* that transaction must necessarily be gone by now.
4355
4363
* for cases where it is a plain TransactionId.
4357
4365
* Note in particular that this covers the case where we already hold
4358
* exclusive lock on the tuple and the caller only wants key share or share
4359
* lock. It would certainly not do to give up the exclusive lock.
4366
* exclusive lock on the tuple and the caller only wants key share or
4367
* share lock. It would certainly not do to give up the exclusive lock.
4361
4369
if (!(old_infomask & (HEAP_XMAX_INVALID |
4362
4370
HEAP_XMAX_COMMITTED |
4382
* If this is the first possibly-multixact-able operation in the
4383
* current transaction, set my per-backend OldestMemberMXactId setting.
4384
* We can be certain that the transaction will never become a member of
4385
* any older MultiXactIds than that. (We have to do this even if we
4386
* end up just using our own TransactionId below, since some other
4387
* backend could incorporate our XID into a MultiXact immediately
4390
* If this is the first possibly-multixact-able operation in the current
4391
* transaction, set my per-backend OldestMemberMXactId setting. We can be
4392
* certain that the transaction will never become a member of any older
4393
* MultiXactIds than that. (We have to do this even if we end up just
4394
* using our own TransactionId below, since some other backend could
4395
* incorporate our XID into a MultiXact immediately afterwards.)
4390
4397
MultiXactIdSetOldestMember();
4419
4426
HeapTupleHeaderSetXmax(tuple->t_data, xid);
4422
* Make sure there is no forward chain link in t_ctid. Note that in the
4429
* Make sure there is no forward chain link in t_ctid. Note that in the
4423
4430
* cases where the tuple has been updated, we must not overwrite t_ctid,
4424
4431
* because it was set by the updater. Moreover, if the tuple has been
4425
* updated, we need to follow the update chain to lock the new versions
4426
* of the tuple as well.
4432
* updated, we need to follow the update chain to lock the new versions of
4433
* the tuple as well.
4428
4435
if (HEAP_XMAX_IS_LOCKED_ONLY(new_infomask))
4429
4436
tuple->t_data->t_ctid = *tid;
4563
4570
else if (old_infomask & HEAP_XMAX_IS_MULTI)
4565
MultiXactStatus new_status;
4572
MultiXactStatus new_status;
4568
* Currently we don't allow XMAX_COMMITTED to be set for multis,
4575
* Currently we don't allow XMAX_COMMITTED to be set for multis, so
4571
4578
Assert(!(old_infomask & HEAP_XMAX_COMMITTED));
4589
4596
* If the XMAX is already a MultiXactId, then we need to expand it to
4590
* include add_to_xmax; but if all the members were lockers and are all
4591
* gone, we can do away with the IS_MULTI bit and just set add_to_xmax
4592
* as the only locker/updater. If all lockers are gone and we have an
4593
* updater that aborted, we can also do without a multi.
4597
* include add_to_xmax; but if all the members were lockers and are
4598
* all gone, we can do away with the IS_MULTI bit and just set
4599
* add_to_xmax as the only locker/updater. If all lockers are gone
4600
* and we have an updater that aborted, we can also do without a
4595
4603
* The cost of doing GetMultiXactIdMembers would be paid by
4596
4604
* MultiXactIdExpand if we weren't to do this, so this check is not
4624
4632
* It's a committed update, so we need to preserve him as updater of
4627
MultiXactStatus status;
4628
MultiXactStatus new_status;
4635
MultiXactStatus status;
4636
MultiXactStatus new_status;
4630
4638
if (old_infomask2 & HEAP_KEYS_UPDATED)
4631
4639
status = MultiXactStatusUpdate;
4633
4641
status = MultiXactStatusNoKeyUpdate;
4635
4643
new_status = get_mxact_status_for_lock(mode, is_update);
4637
4646
* since it's not running, it's obviously impossible for the old
4638
4647
* updater to be identical to the current one, so we need not check
4648
4657
* create a new MultiXactId that includes both the old locker or
4649
4658
* updater and our own TransactionId.
4651
MultiXactStatus status;
4652
MultiXactStatus new_status;
4660
MultiXactStatus status;
4661
MultiXactStatus new_status;
4654
4663
if (HEAP_XMAX_IS_LOCKED_ONLY(old_infomask))
4670
4679
* LOCK_ONLY can be present alone only when a page has been
4671
* upgraded by pg_upgrade. But in that case,
4672
* TransactionIdIsInProgress() should have returned false. We
4680
* upgraded by pg_upgrade. But in that case,
4681
* TransactionIdIsInProgress() should have returned false. We
4673
4682
* assume it's no longer locked in this case.
4675
4684
elog(WARNING, "LOCK_ONLY found for Xid in progress %u", xmax);
4697
4706
if (xmax == add_to_xmax)
4699
LockTupleMode old_mode = TUPLOCK_from_mxstatus(status);
4700
bool old_isupd = ISUPDATE_from_mxstatus(status);
4708
LockTupleMode old_mode = TUPLOCK_from_mxstatus(status);
4709
bool old_isupd = ISUPDATE_from_mxstatus(status);
4703
4712
* We can do this if the new LockTupleMode is higher or equal than
4728
4737
* It's a committed update, so we gotta preserve him as updater of the
4731
MultiXactStatus status;
4732
MultiXactStatus new_status;
4740
MultiXactStatus status;
4741
MultiXactStatus new_status;
4734
4743
if (old_infomask2 & HEAP_KEYS_UPDATED)
4735
4744
status = MultiXactStatusUpdate;
4737
4746
status = MultiXactStatusNoKeyUpdate;
4739
4748
new_status = get_mxact_status_for_lock(mode, is_update);
4741
4751
* since it's not running, it's obviously impossible for the old
4742
4752
* updater to be identical to the current one, so we need not check
4802
4812
xmax = HeapTupleHeaderGetRawXmax(mytup.t_data);
4805
* If this tuple is updated and the key has been modified (or deleted),
4806
* what we do depends on the status of the updating transaction: if
4807
* it's live, we sleep until it finishes; if it has committed, we have
4808
* to fail (i.e. return HeapTupleUpdated); if it aborted, we ignore it.
4809
* For updates that didn't touch the key, we can just plough ahead.
4815
* If this tuple is updated and the key has been modified (or
4816
* deleted), what we do depends on the status of the updating
4817
* transaction: if it's live, we sleep until it finishes; if it has
4818
* committed, we have to fail (i.e. return HeapTupleUpdated); if it
4819
* aborted, we ignore it. For updates that didn't touch the key, we
4820
* can just plough ahead.
4811
4822
if (!(old_infomask & HEAP_XMAX_INVALID) &&
4812
4823
(mytup.t_data->t_infomask2 & HEAP_KEYS_UPDATED))
4814
TransactionId update_xid;
4825
TransactionId update_xid;
4817
4828
* Note: we *must* check TransactionIdIsInProgress before
4890
4901
/* if we find the end of update chain, we're done. */
4891
4902
if (mytup.t_data->t_infomask & HEAP_XMAX_INVALID ||
4892
ItemPointerEquals(&mytup.t_self, &mytup.t_data->t_ctid) ||
4903
ItemPointerEquals(&mytup.t_self, &mytup.t_data->t_ctid) ||
4893
4904
HeapTupleHeaderIsOnlyLocked(mytup.t_data))
4895
4906
UnlockReleaseBuffer(buf);
4906
4917
* heap_lock_updated_tuple
4907
* Follow update chain when locking an updated tuple, acquiring locks (row
4908
* marks) on the updated versions.
4918
* Follow update chain when locking an updated tuple, acquiring locks (row
4919
* marks) on the updated versions.
4910
4921
* The initial tuple is assumed to be already locked.
4912
4923
* This function doesn't check visibility, it just inconditionally marks the
4913
* tuple(s) as locked. If any tuple in the updated chain is being deleted
4924
* tuple(s) as locked. If any tuple in the updated chain is being deleted
4914
4925
* concurrently (or updated with the key being modified), sleep until the
4915
4926
* transaction doing it is finished.
4934
4945
* If this is the first possibly-multixact-able operation in the
4935
* current transaction, set my per-backend OldestMemberMXactId setting.
4936
* We can be certain that the transaction will never become a member of
4937
* any older MultiXactIds than that. (We have to do this even if we
4938
* end up just using our own TransactionId below, since some other
4939
* backend could incorporate our XID into a MultiXact immediately
4946
* current transaction, set my per-backend OldestMemberMXactId
4947
* setting. We can be certain that the transaction will never become a
4948
* member of any older MultiXactIds than that. (We have to do this
4949
* even if we end up just using our own TransactionId below, since
4950
* some other backend could incorporate our XID into a MultiXact
4951
* immediately afterwards.)
4942
4953
MultiXactIdSetOldestMember();
5117
5128
HeapTupleHeaderSetXmax(tuple, InvalidTransactionId);
5120
* The tuple might be marked either XMAX_INVALID or XMAX_COMMITTED
5121
* + LOCKED. Normalize to INVALID just to be sure no one gets
5122
* confused. Also get rid of the HEAP_KEYS_UPDATED bit.
5131
* The tuple might be marked either XMAX_INVALID or XMAX_COMMITTED +
5132
* LOCKED. Normalize to INVALID just to be sure no one gets confused.
5133
* Also get rid of the HEAP_KEYS_UPDATED bit.
5124
5135
tuple->t_infomask &= ~HEAP_XMAX_BITS;
5125
5136
tuple->t_infomask |= HEAP_XMAX_INVALID;
5172
5183
GetMultiXactIdHintBits(MultiXactId multi, uint16 *new_infomask,
5173
5184
uint16 *new_infomask2)
5176
MultiXactMember *members;
5178
uint16 bits = HEAP_XMAX_IS_MULTI;
5180
bool has_update = false;
5181
LockTupleMode strongest = LockTupleKeyShare;
5187
MultiXactMember *members;
5189
uint16 bits = HEAP_XMAX_IS_MULTI;
5191
bool has_update = false;
5192
LockTupleMode strongest = LockTupleKeyShare;
5184
5195
* We only use this in multis we just created, so they cannot be values
5249
5260
static TransactionId
5250
5261
MultiXactIdGetUpdateXid(TransactionId xmax, uint16 t_infomask)
5252
TransactionId update_xact = InvalidTransactionId;
5253
MultiXactMember *members;
5263
TransactionId update_xact = InvalidTransactionId;
5264
MultiXactMember *members;
5256
5267
Assert(!(t_infomask & HEAP_XMAX_LOCK_ONLY));
5257
5268
Assert(t_infomask & HEAP_XMAX_IS_MULTI);
5260
* Since we know the LOCK_ONLY bit is not set, this cannot be a
5261
* multi from pre-pg_upgrade.
5271
* Since we know the LOCK_ONLY bit is not set, this cannot be a multi from
5263
5274
nmembers = GetMultiXactIdMembers(xmax, &members, false);
5265
5276
if (nmembers > 0)
5269
5280
for (i = 0; i < nmembers; i++)
5284
5295
members[i].status == MultiXactStatusUpdate);
5285
5296
update_xact = members[i].xid;
5286
5297
#ifndef USE_ASSERT_CHECKING
5288
5300
* in an assert-enabled build, walk the whole array to ensure
5289
5301
* there's no other updater.
5302
5314
* HeapTupleGetUpdateXid
5303
* As above, but use a HeapTupleHeader
5315
* As above, but use a HeapTupleHeader
5305
5317
* See also HeapTupleHeaderGetUpdateXid, which can be used without previously
5306
5318
* checking the hint bits.
5432
5444
* heap_tuple_needs_freeze
5434
5446
* Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac)
5435
* are older than the specified cutoff XID or MultiXactId. If so, return TRUE.
5447
* are older than the specified cutoff XID or MultiXactId. If so, return TRUE.
5437
5449
* It doesn't matter whether the tuple is alive or dead, we are checking
5438
5450
* to see if a tuple needs to be removed or frozen to avoid wraparound.
added
removed
src/backend/access/heap/heapam.c
