postgres-github.git / summary / log / commit / refs

commit    739477345036c26f0661eedb419058b0b9943f34
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Mon Mar 30 17:59:54 2026 +0000

    Be more careful to preserve consistency of a tuplestore.
    
    Several places in tuplestore.c would leave the tuplestore data
    structure effectively corrupt if some subroutine were to throw
    an error.  Notably, if WRITETUP() failed after some number of
    successful calls within dumptuples(), the tuplestore would
    contain some memtuples pointers that were apparently live
    entries but in fact pointed to pfree'd chunks.
    
    In most cases this sort of thing is fine because transaction
    abort cleanup is not too picky about the contents of memory that
    it's going to throw away anyway.  There's at least one exception
    though: if a Portal has a holdStore, we're going to call
    tuplestore_end() on that, even during transaction abort.
    So it's not cool if that tuplestore is corrupt, and that means
    tuplestore.c has to be more careful.
    
    This oversight demonstrably leads to crashes in v15 and before,
    if a holdable cursor fails to persist its data due to an undersized
    temp_file_limit setting.  Very possibly the same thing can happen in
    v16 and v17 as well, though the specific test case submitted failed
    to fail there (cf. 095555daf).  The failure is accidentally dodged
    as of v18 because 590b045c3 got rid of tuplestore_end's retail tuple
    deletion loop.  Still, it seems unwise to permit tuplestores to become
    internally inconsistent in any branch, so I've applied the same fix
    across the board.
    
    Since the known test case for this is rather expensive and doesn't
    fail in recent branches, I've omitted it.
    
    Bug: #19438
    Reported-by: Dmitriy Kuzmin <kuzmin.db4@gmail.com>
    Author: Tom Lane <tgl@sss.pgh.pa.us>
    Reviewed-by: David Rowley <dgrowleyml@gmail.com>
    Discussion: https://postgr.es/m/19438-9d37b179c56d43aa@postgresql.org
    Backpatch-through: 14

[parent: 681774315d73]