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:
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
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 |