| From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
|---|---|
| To: | Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
| Date: | 2025-10-30 23:48:50 |
| Message-ID: | CAPpHfduQwwa4ytK-dGjRGN0fTWfpWNNysYuUKrOetsyGioBMfA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 28, 2025 at 1:12 AM Dmitry Koval <d(dot)koval(at)postgrespro(dot)ru> wrote:
> 1.
> > The second CommandCounterIncrement() is needed to make the renamed
> > relation visible within our transaction. Why do we need the first
> >one? I see tests pass without it.
>
> It's strange. If I comment the first "CommandCounterIncrement();", in block
> -----------------------------------------------------------------------
> /*
> * We must bump the command counter to make the split partition tuple
> * visible for renaming.
> */
> CommandCounterIncrement();
> /* Rename partition. */
> sprintf(tmpRelName, "split-%u-%X-tmp", RelationGetRelid(rel), ...);
> RenameRelationInternal(splitRelOid, tmpRelName, true, false);
> /*
> * We must bump the command counter to make the split partition tuple
> * visible after renaming.
> */
> CommandCounterIncrement();
> -----------------------------------------------------------------------
> , I got the error "ERROR: tuple already updated by self" in the
> partition_split.sql test (Ubuntu). If I comment the second
> "CommandCounterIncrement();", I got the error "ERROR: relation
> "sales_others" already exists" in the same test.
Sorry, actually it fails. It appears that the first
CommandCounterIncrement() is needed to see the result of
detachPartitionTable().
> 2.
> >The branch handling null value in the outer loop, uses null2 flag from
> >the inner loop. I think for the null value of the outer loop we still
> >need to run inner loop to search for the matching null value.
>
> This code looks a little confusing, but it probably works correctly.
> This can be verified using two typical examples:
> -----------------------------------------------------------------------
> list1: (NULL, 1)
> list2: (2, NULL)
>
> (1) isnull1 = true, (2) "if (isnull1) lappend(NULL)"
> -----------------------------------------------------------------------
> list1: (1, NULL)
> list2: (NULL, 2)
>
> (1) isnull2 = true, (2) "if (isnull2) lappend(NULL)"
> -----------------------------------------------------------------------
> In both cases, we return from the function immediately after lappend.
> This works because we need to find exactly one repeating value.
How this function could handle this case?
list1: (NULL)
list2: whatever containing NULL
The outer loop will just quit after iterating the only element of
list1 without even iterating list2.
------
Regards,
Alexander Korotkov
Supabase
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2025-10-31 00:38:15 | Re: another autovacuum scheduling thread |
| Previous Message | Mihail Nikalayeu | 2025-10-30 23:35:00 | Re: Extend injection_points_attach() to accept a user-defined function |