• Tom Lane's avatar
    Avoid corrupting tables when ANALYZE inside a transaction is rolled back. · e0722d9c
    Tom Lane authored
    VACUUM and ANALYZE update the target table's pg_class row in-place, that is
    nontransactionally.  This is OK, more or less, for the statistical columns,
    which are mostly nontransactional anyhow.  It's not so OK for the DDL hint
    flags (relhasindex etc), which might get changed in response to
    transactional changes that could still be rolled back.  This isn't a
    problem for VACUUM, since it can't be run inside a transaction block nor
    in parallel with DDL on the table.  However, we allow ANALYZE inside a
    transaction block, so if the transaction had earlier removed the last
    index, rule, or trigger from the table, and then we roll back the
    transaction after ANALYZE, the table would be left in a corrupted state
    with the hint flags not set though they should be.
    
    To fix, suppress the hint-flag updates if we are InTransactionBlock().
    This is safe enough because it's always OK to postpone hint maintenance
    some more; the worst-case consequence is a few extra searches of pg_index
    et al.  There was discussion of instead using a transactional update,
    but that would change the behavior in ways that are not all desirable:
    in most scenarios we're better off keeping ANALYZE's statistical values
    even if the ANALYZE itself rolls back.  In any case we probably don't want
    to change this behavior in back branches.
    
    Per bug #11638 from Casey Shobe.  This has been broken for a good long
    time, so back-patch to all supported branches.
    
    Tom Lane and Michael Paquier, initial diagnosis by Andres Freund
    e0722d9c
vacuum.c 45.1 KB