Re: pgsql: Avoid corrupting tables when ANALYZE inside a transaction is rol - Mailing list pgsql-committers

From Noah Misch
Subject Re: pgsql: Avoid corrupting tables when ANALYZE inside a transaction is rol
Date
Msg-id 20141030040936.GA407655@tornado.leadboat.com
Whole thread Raw
In response to pgsql: Avoid corrupting tables when ANALYZE inside a transaction is rol  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: pgsql: Avoid corrupting tables when ANALYZE inside a transaction is rol
List pgsql-committers
On Wed, Oct 29, 2014 at 10:12:44PM +0000, Tom Lane wrote:
> Avoid corrupting tables when ANALYZE inside a transaction is rolled back.
>
> 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().

Shouldn't this use IsInTransactionChain(), to catch the other ways ANALYZE can
share a transaction with DDL?


pgsql-committers by date:

Previous
From: Peter Eisentraut
Date:
Subject: pgsql: Remove use of TAP subtests
Next
From: Tom Lane
Date:
Subject: Re: Re: pgsql: Avoid corrupting tables when ANALYZE inside a transaction is rol