Horton

Re: [WIP]Vertical Clustered Index (columnar store extension) - take2

Peter Smith <smithpb2250@gmail.com>

View thread
From: Peter Smith <smithpb2250@gmail.com>
To: Timur Magomedov <t.magomedov@postgrespro.ru>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas@vondra.me>, "Aya Iwata (Fujitsu)" <iwata.aya@fujitsu.com>, Japin Li <japinli@hotmail.com>, shveta malik <shveta.malik@gmail.com>
Date: 2025-09-25T01:47:54Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Mark ItemPointer arguments as const throughout

  2. Reorganize GUC structs

  3. Eliminate XLOG_HEAP2_VISIBLE from vacuum phase III

  4. Update various forward declarations to use typedef

  5. Pathify RHS unique-ification for semijoin planning

  6. Revert "Don't lock partitions pruned by initial pruning"

  7. For inplace update, send nontransactional invalidations.

  8. Remove nearly-unused SizeOfIptrData macro.

Hi Timur.

On Wed, Sep 24, 2025 at 11:47 PM Timur Magomedov
<t.magomedov@postgrespro.ru> wrote:
...
> >
> > Thanks for the patch! Unfortunately, this is straying into areas with
> > which I'm not familiar, so I'm taking it on faith that these are good
> > changes. For now, I'm happy to merge your patch into the next VCI
> > version, posted unless someone else objects.
> >
> > ~
> >
> > But, I still have a couple of questions for clarification:
> >
> > 1. What about the original Valgrind issue?
> >
> > Is that still a problem that needs to be addressed? E.g., is the bad
> > allocation still lurking, and your sort avoidance patch is simply
> > preventing the bad allocation from being exposed until some next
> > thing
> > randomly fails? Or is there no allocation problem anymore to worry
> > about?
>
> Allocations are fine, the problem was using some nodes as nodes of
> another type (and bigger size) which leads to crossing boundary of
> allocated memory. We are safe now and asserts guard us from repeating
> the original bug.
>

Thanks for the clarification.

>
> > 2. What about your added Assert that was previously failing at
> > executor/vci_sort.c:89?
> >
> > That Assert is still present in vci_sort.c, but AFAICT the current
> > tests are not executing that code. Do those patched GUC changes
> > simply
> > make that code unreachable now? In other words, should that
> > previously
> > failing Assert be left where it is or not? Should there be another
> > test case added to execute this Assert?
>
> Added simple test for running VCI sort node, it executes the assertion
> code in vci_sort.c. No assertion fails, so VCI Sort itself is OK. Here
> are both two commits on top of v25 version.
>

These have been included in v26. Thanks!

======
Kind Regards,
Peter Smith.
Fujitsu Australia