On Tue, Mar 24, 2020 at 6:01 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > While messing with EXPLAIN on a query emitted by pg_dump, I noticed that > > current Postgres 10 emits weird bucket/batch/memory values for certain > > hash nodes: > > > -> Hash (cost=0.11..0.11 rows=10 width=12) > > (actual time=0.002..0.002 rows=1 loops=8) > > Buckets: 2139062143 Batches: 2139062143 > > Memory Usage: 8971876904722400kB > > -> Function Scan on unnest init_1 > > (cost=0.01..0.11 rows=10 width=12) (actual time=0.001..0.001 rows=1 loops=8) > > Looks suspiciously like uninitialized memory ...
I think "hashtable" might have been pfree'd before ExecHashGetInstrumentation() ran, because those numbers look like CLOBBER_FREED_MEMORY's pattern: >>> hex(2139062143) '0x7f7f7f7f' >>> hex(8971876904722400 / 1024) '0x7f7f7f7f7f7' Maybe there is something wrong with the shutdown order of nested subplans.