BUG #19020: BufFileDumpBuffer writes uninitialized data on executing hash join - Mailing list pgsql-bugs

From PG Bug reporting form
Subject BUG #19020: BufFileDumpBuffer writes uninitialized data on executing hash join
Date
Msg-id 19020-2028eba94974a545@postgresql.org
Whole thread Raw
Responses Re: BUG #19020: BufFileDumpBuffer writes uninitialized data on executing hash join
List pgsql-bugs
The following bug has been logged on the website:

Bug reference:      19020
Logged by:          Alexander Lakhin
Email address:      exclusion@gmail.com
PostgreSQL version: 18beta3
Operating system:   Ubuntu 24.04
Description:

The following script, when executed under Valgrind:
CREATE TABLE tenk1 (
                unique1         int4,
                unique2         int4,
                two                     int4,
                stud_emp                int4,
                ten                     int4,
                twenty          int4,
                hundred         int4,
                thousand        int4,
                twothousand     int4,
                fivethous       int4,
                tenthous        int4,
                odd                     int4,
                even            int4,
                stringu1        name,
                stringu2        name,
                string4         name
        );

COPY tenk1 FROM '.../src/test/regress/data/tenk.data';
VACUUM ANALYZE tenk1;

SET work_mem = '64kB';
SELECT COUNT(*) FROM tenk1 JOIN generate_series(1, 1300) g ON unique1 = g;

triggers an error:
==00:00:00:06.424 2914013== Syscall param pwrite64(buf) points to
uninitialised byte(s)
==00:00:00:06.424 2914013==    at 0x4FF8517: pwrite (pwrite64.c:25)
==00:00:00:06.424 2914013==    by 0x7C10E8: pg_pwritev (pg_iovec.h:101)
==00:00:00:06.424 2914013==    by 0x7C3BD1: FileWriteV (fd.c:2293)
==00:00:00:06.424 2914013==    by 0x7BEB0A: FileWrite (fd.h:219)
==00:00:00:06.424 2914013==    by 0x7BF685: BufFileDumpBuffer
(buffile.c:538)
==00:00:00:06.424 2914013==    by 0x7BFC6A: BufFileFlush (buffile.c:724)
==00:00:00:06.424 2914013==    by 0x7BF841: BufFileReadCommon
(buffile.c:600)
==00:00:00:06.424 2914013==    by 0x7BFACD: BufFileReadMaybeEOF
(buffile.c:667)
==00:00:00:06.424 2914013==    by 0x54FC94: ExecHashJoinGetSavedTuple
(nodeHashjoin.c:1476)
==00:00:00:06.424 2914013==    by 0x54F140: ExecHashJoinOuterGetTuple
(nodeHashjoin.c:1042)
==00:00:00:06.424 2914013==    by 0x54E139: ExecHashJoinImpl
(nodeHashjoin.c:432)
==00:00:00:06.424 2914013==    by 0x54E7D2: ExecHashJoin
(nodeHashjoin.c:690)
==00:00:00:06.424 2914013==  Address 0x11dc8a88 is 80 bytes inside a block
of size 8,264 client-defined
==00:00:00:06.424 2914013==    at 0xA651F2: palloc (mcxt.c:1389)
==00:00:00:06.424 2914013==    by 0x7BEB39: makeBufFileCommon
(buffile.c:120)
==00:00:00:06.424 2914013==    by 0x7BEBB1: makeBufFile (buffile.c:141)
==00:00:00:06.424 2914013==    by 0x7BED3C: BufFileCreateTemp
(buffile.c:212)
==00:00:00:06.424 2914013==    by 0x54FBE6: ExecHashJoinSaveTuple
(nodeHashjoin.c:1437)
==00:00:00:06.424 2914013==    by 0x54E309: ExecHashJoinImpl
(nodeHashjoin.c:494)
==00:00:00:06.424 2914013==    by 0x54E7D2: ExecHashJoin
(nodeHashjoin.c:690)
==00:00:00:06.424 2914013==    by 0x521ED9: ExecProcNodeFirst
(execProcnode.c:469)
==00:00:00:06.424 2914013==    by 0x533ADB: ExecProcNode (executor.h:315)
==00:00:00:06.424 2914013==    by 0x5340B1: fetch_input_tuple
(nodeAgg.c:563)
==00:00:00:06.424 2914013==    by 0x5377C9: agg_retrieve_direct
(nodeAgg.c:2450)
==00:00:00:06.424 2914013==    by 0x537399: ExecAgg (nodeAgg.c:2265)
==00:00:00:06.424 2914013==
...
==00:00:00:06.496 2915423== Exit program on first error
(--exit-on-first-error=yes)
2025-08-16 11:28:47.537 UTC [2915382] LOG:  client backend (PID 2915423)
exited with exit code 1
2025-08-16 11:28:47.537 UTC [2915382] DETAIL:  Failed process was running:
SELECT COUNT(*) FROM tenk1 JOIN generate_series(1, 1300) g ON unique1 = g;

Reproduced on REL_13_STABLE .. master.


pgsql-bugs by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: BUG #18988: DROP SUBSCRIPTION locks not-yet-accessed database
Next
From: Arseniy Mukhin
Date:
Subject: Re: BUG #19018: high memory usage and "stack depth limit exceeded", with GiST index on ltree