On Tue, Mar 24, 2020 at 11:05 AM Thomas Munro <thomas.mu...@gmail.com> wrote:
> On Tue, Mar 24, 2020 at 9:55 AM Thomas Munro <thomas.mu...@gmail.com> > wrote: > > 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. > > I think there might be a case like this: > > * ExecRescanHashJoin() decides it can't reuse the hash table for a > rescan, so it calls ExecHashTableDestroy(), clears HashJoinState's > hj_HashTable and sets hj_JoinState to HJ_BUILD_HASHTABLE > * the HashState node still has a reference to the pfree'd HashJoinTable! > * HJ_BUILD_HASHTABLE case reaches the empty-outer optimisation case so > it doesn't bother to build a new hash table > * EXPLAIN examines the HashState's pointer to a freed HashJoinTable struct > Yes, debugging with gdb shows this is exactly what happens. Thanks Richard
