Re: BUG #11638: Transaction safety fails when constraints are dropped and analyze is done

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: cg(at)osss(dot)net, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #11638: Transaction safety fails when constraints are dropped and analyze is done
Date: 2014-10-15 06:02:43
Message-ID: CAB7nPqTsZUnDNYgLZ8OO5T4rQY+=XSe7uomiv=OVQnJvVzzHJg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Oct 15, 2014 at 2:12 PM, Andres Freund <andres(at)2ndquadrant(dot)com>
wrote:

> I'm not sure which danger you're seeing here. Imo we need to choose
> between heap_inplace/heap_update for VACUUM/ANALYZE because one is
> allowed to run in a transaction, and the other is not. It simply *can't*
> be safe for ANALYZE to set things like relhastriggers = false using
> heap_inplace().
> There's problems with both it rolling back and thus undoing the action
> that allowed relhastriggers = false to be set and scenarios where it's
> not ok that other backends can see that value before the transaction
> committed.

Hm, I was wondering about the potential effects of VACUUM FULL or VACUUM
ANALYZE, but as they cannot run in a tx block... Btw, I have just put my
hands on this code and made the attached to make vac_update_relstats able
to do a transactional update. It looks to work fine with only a check on
the flags of vacuum statement.
Regards,
--
Michael

Attachment Content-Type Size
20141015_analyze_transactional.patch text/x-diff 3.1 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2014-10-15 06:18:15 Re: BUG #11638: Transaction safety fails when constraints are dropped and analyze is done
Previous Message Andres Freund 2014-10-15 05:12:54 Re: BUG #11638: Transaction safety fails when constraints are dropped and analyze is done