Re: minor fix in CancelVirtualTransaction

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: minor fix in CancelVirtualTransaction
Date: 2019-01-04 10:54:42
Message-ID: c80a4866-00fc-b012-9b77-80c3e7e69be8@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/12/2018 21:37, Alvaro Herrera wrote:
> When scanning the list of virtual transactions looking for one
> particular vxid, we cancel the transaction *and* break out of the loop
> only if both backendId and localTransactionId matches us. The canceling
> part is okay, but limiting the break to that case is pointless: if we
> found the correct backendId, there cannot be any other entry with the
> same backendId. Rework the loop so that we break out of it if backendId
> matches even if the localTransactionId part doesn't.

Your reasoning seems correct to me.

Maybe add a code comment along the lines of "once we have found the
right ... we don't need to check the remaining ...".

Or, you can make this even more clear by comparing the backendId
directly with the proc entry:

if (vxid.backendId == proc->backendId)
{
if (vxid.localTransactionId == proc->lxid)
{

}
break;
}

Then the logic your are trying to achieve would be obvious.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Charles Clavadetscher 2019-01-04 10:56:22 RE: Potentially undocumented behaviour change in Postgres 11 concerning OLD record in an after insert trigger
Previous Message Kristjan Tammekivi 2019-01-04 10:45:42 Potentially undocumented behaviour change in Postgres 11 concerning OLD record in an after insert trigger