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
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 |