Re: BUG #17855: Uninitialised memory used when the name type value processed in binary mode of Memoize

Hi David,

25.03.2023 08:32, David Rowley wrote:
> The attached is just a draft so far. It'll need more comments to
> document what the code is all about. I don't want to spend too much
> time on it if this isn't going to be the final solution.

I've stumbled upon this issue one more time. With a query like this:
CREATE TABLE t(id integer, node name);
CREATE INDEX t_id_node_idx ON t(id, node);
INSERT INTO t VALUES (1, 'node1');

EXPLAIN SELECT array_agg(node ORDER BY node) AS node_list FROM t GROUP BY id;
SELECT array_agg(node ORDER BY node) AS node_list FROM t GROUP BY id;

I get (on REL_16_STABLE):
                                      QUERY PLAN
--------------------------------------------------------------------------------------
 GroupAggregate  (cost=0.15..67.65 rows=200 width=36)
   Group Key: id
   ->  Index Only Scan using t_id_node_idx on t (cost=0.15..60.90 rows=850 width=68)

(Note that this time the error is triggered without the Memoize node.)

==00:00:00:04.385 3941088== Uninitialised byte(s) found during client check request
==00:00:00:04.385 3941088==    at 0x1F0CF7: printtup (printtup.c:349)
==00:00:00:04.385 3941088==    by 0x410521: ExecutePlan (execMain.c:1701)
==00:00:00:04.385 3941088==    by 0x4106B3: standard_ExecutorRun (execMain.c:365)
==00:00:00:04.385 3941088==    by 0x41078D: ExecutorRun (execMain.c:309)
==00:00:00:04.385 3941088==    by 0x5FAC9A: PortalRunSelect (pquery.c:924)
==00:00:00:04.385 3941088==    by 0x5FC63B: PortalRun (pquery.c:768)
==00:00:00:04.385 3941088==    by 0x5F85F3: exec_simple_query (postgres.c:1274)
==00:00:00:04.385 3941088==    by 0x5FA593: PostgresMain (postgres.c:4637)
==00:00:00:04.385 3941088==    by 0x5514A2: BackendRun (postmaster.c:4464)
==00:00:00:04.385 3941088==    by 0x554658: BackendStartup (postmaster.c:4192)
==00:00:00:04.385 3941088==    by 0x5547F6: ServerLoop (postmaster.c:1782)
==00:00:00:04.385 3941088==    by 0x555D26: PostmasterMain (postmaster.c:1466)
==00:00:00:04.385 3941088==  Address 0x1121ecdc is 36 bytes inside a block of size 88 client-defined
==00:00:00:04.385 3941088==    at 0x77EDA5: palloc0 (mcxt.c:1282)
==00:00:00:04.385 3941088==    by 0x62B6BC: construct_md_array (arrayfuncs.c:3528)
==00:00:00:04.385 3941088==    by 0x631013: makeMdArrayResult (arrayfuncs.c:5427)
==00:00:00:04.385 3941088==    by 0x6242AF: array_agg_finalfn (array_userfuncs.c:858)
==00:00:00:04.385 3941088==    by 0x4247F5: finalize_aggregate (nodeAgg.c:1120)
==00:00:00:04.385 3941088==    by 0x42620A: finalize_aggregates (nodeAgg.c:1361)
==00:00:00:04.385 3941088==    by 0x426E71: agg_retrieve_direct (nodeAgg.c:2520)
==00:00:00:04.385 3941088==    by 0x4272B9: ExecAgg (nodeAgg.c:2180)
==00:00:00:04.385 3941088==    by 0x417EE1: ExecProcNodeFirst (execProcnode.c:464)
==00:00:00:04.385 3941088==    by 0x4104F0: ExecProcNode (executor.h:273)
==00:00:00:04.385 3941088==    by 0x4104F0: ExecutePlan (execMain.c:1670)
==00:00:00:04.385 3941088==    by 0x4106B3: standard_ExecutorRun (execMain.c:365)
==00:00:00:04.385 3941088==    by 0x41078D: ExecutorRun (execMain.c:309)
==00:00:00:04.385 3941088==

With your last patch applied I see no this valgrind complaint.

Maybe it makes sense to register the proposed patch on the commitfest at
least to keep it in sight?

Best regards,
Alexander Lakhin