minor fix in CancelVirtualTransaction

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

minor fix in CancelVirtualTransaction

Álvaro Herrera
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/

0001-fixup-CancelVirtualTransaction.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: minor fix in CancelVirtualTransaction

Alvaro Herrera-9
Same patch, commit message added.  Adding to commitfest.

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

0001-Optimize-CancelVirtualTransaction-a-little-bit.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: minor fix in CancelVirtualTransaction

Peter Eisentraut-6
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

Reply | Threaded
Open this post in threaded view
|

Re: minor fix in CancelVirtualTransaction

Alvaro Herrera-9
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

v2-0001-fixup-CancelVirtualTransaction.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: minor fix in CancelVirtualTransaction

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