Thread: minor fix in CancelVirtualTransaction
It looks to me like we're missing a trick in CancelVirtualTransaction -- there's a loop to compare all VXIDs, and we break as soon as find a perfect match in (backendid, localTransactionId). However, once we've found the backendId that matches, it's not possible for there to be another entry with the same backendId, so we might as well just quit the loop, even if we don't send a signal. No, I don't know if this shows in profiles. I just noticed while reading code. Attached patch (git diff --ignore-space-change; needs reindent) illustrates. This was added by commit efc16ea52067 (Dec 2009) and seems unchanged since then. -- Álvaro Herrera Developer, https://www.PostgreSQL.org/
Attachment
Same patch, commit message added. Adding to commitfest. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
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
On 2019-Jan-04, Peter Eisentraut wrote: > 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: I did both (the second idea was a non-obvious very nice cleanup -- thanks). Patch attached. However, now I realize that this code is not covered at all, so I'll put this patch to sleep until I write some test for it. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
Hi, On 2019-01-11 18:35:13 -0300, Alvaro Herrera wrote: > On 2019-Jan-04, Peter Eisentraut wrote: > > > 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: > > I did both (the second idea was a non-obvious very nice cleanup -- > thanks). Patch attached. > > However, now I realize that this code is not covered at all, so I'll put > this patch to sleep until I write some test for it. Given that the CF entry has been waiting on this update I'll mark this as returned with feedback, rather than moving to the next CF. Greetings, Andres Freund