Horton

Re: Use generation memory context for tuplestore.c

Alexander Law <exclusion@gmail.com>

View thread View on postgr.es
From: Alexander Lakhin <exclusion@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-05T04:00:00Z
Lists: pgsql-hackers 
Hello David,

03.07.2024 13:41, David Rowley wrote:
>
>> Lastly, I think this would benefit from a test in
>> regress/sql/explain.sql, as the test changes that were included
>> removed the only occurrance of a Materialize node from the regression
>> tests' EXPLAIN outputs.
> I've modified the tests where the previous patch disabled
> enable_material to enable it again and mask out the possibly unstable
> part. Do you think that's an ok level of testing?

Please look at a segfault crash introduced with 1eff8279d:
CREATE TABLE t1(i int);
CREATE TABLE t2(i int) PARTITION BY RANGE (i);
CREATE TABLE t2p PARTITION OF t2 FOR VALUES FROM (1) TO (2);

EXPLAIN ANALYZE SELECT * FROM t1 JOIN t2 ON t1.i > t2.i;

Leads to:
Core was generated by `postgres: law regression [local] EXPLAIN                                      '.
Program terminated with signal SIGSEGV, Segmentation fault.

#0  0x000055c36dbac2f7 in tuplestore_storage_type_name (state=0x0) at tuplestore.c:1476
1476            if (state->status == TSS_INMEM)

Best regards,
Alexander

Commits

  1. Adjust tuplestore.c not to allocate BufFiles in generation context

  2. Fix incorrect sentinel byte logic in GenerationRealloc()

  3. Improve memory management and performance of tuplestore.c

  4. Fix newly introduced issue in EXPLAIN for Materialize nodes

  5. Add memory/disk usage for Material nodes in EXPLAIN