minor fix in CancelVirtualTransaction

Started by Alvaro Herreraalmost 8 years ago5 messageshackers
Jump to latest
#1Alvaro Herrera
alvherre@2ndquadrant.com

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/

Attachments:

0001-fixup-CancelVirtualTransaction.patchtext/plain; charset=us-asciiDownload+4-2
#2Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Alvaro Herrera (#1)
Re: minor fix in CancelVirtualTransaction

Same patch, commit message added. Adding to commitfest.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachments:

0001-Optimize-CancelVirtualTransaction-a-little-bit.patchtext/x-diff; charset=us-asciiDownload+12-11
#3Peter Eisentraut
peter_e@gmx.net
In reply to: Alvaro Herrera (#2)
Re: minor fix in CancelVirtualTransaction

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

#4Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Peter Eisentraut (#3)
Re: minor fix in CancelVirtualTransaction

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

Attachments:

v2-0001-fixup-CancelVirtualTransaction.patchtext/x-diff; charset=us-asciiDownload+8-6
#5Andres Freund
andres@anarazel.de
In reply to: Alvaro Herrera (#4)
Re: minor fix in CancelVirtualTransaction

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