Re: Yet another small patch - reorderbuffer.c:1099 - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Yet another small patch - reorderbuffer.c:1099
Date
Msg-id CAB7nPqTvzAxvTuBQh+MTuPVfwHUeMq30z0hrVT3fWoYD-q71gA@mail.gmail.com
Whole thread Raw
In response to Yet another small patch - reorderbuffer.c:1099  (Aleksander Alekseev <a.alekseev@postgrespro.ru>)
Responses Re: Yet another small patch - reorderbuffer.c:1099
List pgsql-hackers
On Tue, Apr 5, 2016 at 1:03 AM, Aleksander Alekseev
<a.alekseev@postgrespro.ru> wrote:
> There is weird peace of code in reorderbuffer.c:
>
> ```
>     /* delete from list of known subxacts */
>     if (txn->is_known_as_subxact)
>     {
>         /* NB: nsubxacts count of parent will be too high now */
>         dlist_delete(&txn->node);
>     }
>     /* delete from LSN ordered list of toplevel TXNs */
>     else
>     {
>         dlist_delete(&txn->node);
>     }
> ```
>
> As you see `if` an `else` branches are exactly the same. I wonder
> whether this is a bug or code just requires a bit of cleaning. In the
> latter case here is a patch.
>
> According to `git log` both branches were introduced in one commit
> b89e1510. I added author and committer of this code to CC since they
> have much better understanding of it than I do.

I recall discussing this code with Andres, and I think that he has
mentioned me this is intentional, because should things be changed for
a reason or another in the future, we want to keep in mind that a list
of TXIDs and a list of sub-TXIDs should be handled differently.
-- 
Michael



pgsql-hackers by date:

Previous
From: Armin Schöffmann
Date:
Subject: PATCH: pg_restore parallel-execution-deadlock issue
Next
From: David Rowley
Date:
Subject: Re: oversight in parallel aggregate