Re: CLUSTER FREEZE

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <munro(at)ip9(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CLUSTER FREEZE
Date: 2014-01-02 21:01:10
Message-ID: CA+TgmobNU9cfmJD8LODY5K37PGKErGdOpgcs5uee8xtXUR9Abw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 23, 2013 at 6:53 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2013-12-22 20:45:02 -0500, Robert Haas wrote:
>> I suspect we ought to extend this to rewriting variants of ALTER TABLE
>> as well, but a little thought is needed there. ATRewriteTables()
>> appears to just call heap_insert() for each updated row, which if I'm
>> not mistaken is an MVCC violation - offhand, it seems like a
>> transaction with an older MVCC snapshot could access the table for
>> this first time after the rewriter commits, and fail to see rows which
>> would have appeared to be there before the rewrite. (I haven't
>> actually tested this, so watch me be wrong.) If we're OK with an MVCC
>> violation here, we could just pass HEAP_INSERT_FROZEN and have a
>> slightly different flavor of violation; if not, this needs some kind
>> of more extensive surgery quite apart from what we do about freezing.
>
> Yes, rewriting ALTER TABLEs certainly aren't MVCC safe. I thought that
> was documented, but apparently not.
> I am not sure it can be fixed easily using the tricks CLUSTER plays,
> there might be nasty edge-cases because of the changes in the column
> definition. Certainly not a trivial project.
>
> I think we should leave ALTER TABLE as a completely separate project and
> just improve CLUSTER for now. The practical impact of rewriting ALTER
> TABLEs not freezing is far smaller, because they are very seldomly
> performed in bigger databases.

OK, I have committed my patch to make CLUSTER and VACUUM FULL freeze
aggressively, and have left ALTER TABLE alone for now.

It would be nice to get to the point where a database-wide VACUUM FULL
would serve to bump datfrozenxid, so as to avoid having to give this
sort of advice:

http://www.postgresql.org/message-id/CA+Tgmobth=AQkwMWtCsQLAEnV59GT4g3oqPQS45CB+fvG9MxSA@mail.gmail.com

However, it doesn't, quite: a bare VACUUM FULL now bumps relfrozenxid
for every table in the database *except pg_class*. It does call
vac_update_datfrozenxid() afterwards, but that only helps if pg_class
is not among the things holding back datfrozenxid. I haven't dug into
this much yet, but I think it might be worth fixing.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-01-02 21:05:09 Re: ERROR: missing chunk number 0 for toast value
Previous Message Andres Freund 2014-01-02 20:19:14 Re: ERROR: missing chunk number 0 for toast value