mirror of
https://github.com/postgres/postgres.git
synced 2025-05-06 19:59:18 +03:00
Partially roll back overenthusiastic SSI optimization.
When a regular lock is held, SSI can use that in lieu of a predicate lock to detect rw conflicts; but if the regular lock is being taken by a subtransaction, we can't assume that it'll commit, so releasing the parent transaction's lock in that case is a no-no. Kevin Grittner
This commit is contained in:
parent
9c38bce29c
commit
fbc0d07796
@ -3638,14 +3638,20 @@ CheckTargetForConflictsIn(PREDICATELOCKTARGETTAG *targettag)
|
|||||||
if (sxact == MySerializableXact)
|
if (sxact == MySerializableXact)
|
||||||
{
|
{
|
||||||
/*
|
/*
|
||||||
* If we're getting a write lock on the tuple, we don't need a
|
* If we're getting a write lock on the tuple and we're not in a
|
||||||
* predicate (SIREAD) lock. At this point our transaction already
|
* subtransaction, we don't need a predicate (SIREAD) lock. We
|
||||||
* has an ExclusiveRowLock on the relation, so we are OK to drop
|
* can't use this optimization within a subtransaction because
|
||||||
* the predicate lock on the tuple, if found, without fearing that
|
* the subtransaction could be rolled back, and we would be left
|
||||||
* another write against the tuple will occur before the MVCC
|
* without any lock at the top level.
|
||||||
* information makes it to the buffer.
|
*
|
||||||
|
* At this point our transaction already has an ExclusiveRowLock
|
||||||
|
* on the relation, so we are OK to drop the predicate lock on
|
||||||
|
* the tuple, if found, without fearing that another write
|
||||||
|
* against the tuple will occur before the MVCC information
|
||||||
|
* makes it to the buffer.
|
||||||
*/
|
*/
|
||||||
if (GET_PREDICATELOCKTARGETTAG_OFFSET(*targettag))
|
if (!IsSubTransaction()
|
||||||
|
&& GET_PREDICATELOCKTARGETTAG_OFFSET(*targettag))
|
||||||
{
|
{
|
||||||
uint32 predlockhashcode;
|
uint32 predlockhashcode;
|
||||||
PREDICATELOCKTARGET *rmtarget = NULL;
|
PREDICATELOCKTARGET *rmtarget = NULL;
|
||||||
|
Loading…
x
Reference in New Issue
Block a user