From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, RhodiumToad on IRC <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade bug found! |
Date: | 2011-04-08 01:10:41 |
Message-ID: | 1302225041.21328.6.camel@jdavis-ux.asterdata.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2011-04-07 at 20:14 -0400, Bruce Momjian wrote:
> So I think we have four possible approaches to correct databases:
>
> 1) SELECT * to set the hint bits
> 2) VACUUM to set the hint bits
> 3) VACUUM FREEZE to remove the old xids
> 4) some complicated function
>
> I don't like #4, and I think I can script #2 and #3 in psql by using COPY
> to create a VACUUM script and then run it with \i. #1 is easy in a DO
> block with PL/pgSQL.
The only one that sounds very reasonable to me is #3. If there are any
xids older than the relfrozenxid, we need to get rid of them. If there
is some reason that doesn't work, I suppose we can consider the
alternatives. But I don't like the hint-bit-setting approach much.
What if the xmax is really a transaction that got an exclusive lock on
the tuple, rather than actually deleting it? Are you sure that a SELECT
(or even a normal VACUUM) would get rid of that xid, or might something
still try to look it up in the clog later?
Not only that, but hint-bit-setting is not WAL-logged, so you'd really
have to do a checkpoint afterward.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-04-08 01:33:19 | Re: pg_upgrade bug found! |
Previous Message | Bruce Momjian | 2011-04-08 00:14:18 | Re: pg_upgrade bug found! |