Thread: some pointless HeapTupleHeaderIndicatesMovedPartitions calls
Hello Pavan Deolasee recently noted that a few of the HeapTupleHeaderIndicatesMovedPartitions calls added by commit 5db6df0c0117 are useless, since they are done after comparing t_self with t_ctid. That's because t_self can never be set to the magical values that indicate that the tuple moved partition. If the first test fails (so we know t_self equals t_ctid), necessarily the second test will also fail. So these checks can be removed and no harm is done. -- Álvaro Herrera 39°49'30"S 73°17'W
Attachment
Hi Alvaro,
On Tue, Sep 29, 2020 at 10:14 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
Hello
Pavan Deolasee recently noted that a few of the
HeapTupleHeaderIndicatesMovedPartitions calls added by commit
5db6df0c0117 are useless, since they are done after comparing t_self
with t_ctid. That's because t_self can never be set to the magical
values that indicate that the tuple moved partition. If the first
test fails (so we know t_self equals t_ctid), necessarily the second
test will also fail.
So these checks can be removed and no harm is done.
The patch looks good to me. The existing coding pattern was a bit confusing and that's how I noticed it. So +1 for fixing it.
Thanks,
Pavan
Pavan Deolasee
The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation: not tested I wonder, why this patch hangs on commitfest for so long. The idea of the fix is clear, the code is correct and all tests pass, so, I move it to ReadyForCommitter status. The new status of this patch is: Ready for Committer
On Fri, Feb 12, 2021 at 04:42:26PM +0000, Anastasia Lubennikova wrote: > I wonder, why this patch hangs on commitfest for so long. > The idea of the fix is clear, the code is correct and all tests pass, so, I move it to ReadyForCommitter status. > > The new status of this patch is: Ready for Committer So that's this patch: https://commitfest.postgresql.org/32/2941/. Alvaro is most likely going to take care of that, so let's wait for him. -- Michael