From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | depesz <depesz(at)depesz(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] pg_upgrade problem |
Date: | 2011-08-29 18:41:38 |
Message-ID: | 1314643001-sup-6186@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Excerpts from hubert depesz lubaczewski's message of lun ago 29 14:49:24 -0300 2011:
> On Mon, Aug 29, 2011 at 06:54:41PM +0200, hubert depesz lubaczewski wrote:
> > On Fri, Aug 26, 2011 at 05:28:35PM +0200, hubert depesz lubaczewski wrote:
> > > On Fri, Aug 26, 2011 at 12:18:55AM -0400, Bruce Momjian wrote:
> > > >
> > > > OK, this was very helpful. I found out that there is a bug in current
> > > > 9.0.X, 9.1.X, and HEAD that I introduced recently when I excluded temp
> > > > tables. (The bug is not in any released version of pg_upgrade.) The
> > > > attached, applied patches should fix it for you. I assume you are
> > > > running 9.0.X, and not 9.0.4.
> > >
> > > pg_upgrade worked. Now I'm doing reindex and later on vacuumdb -az.
> >
> > vacuumdb failed. The fail looks very similar to the one I had on 9.0.4.
> >
> > After long vacuum I got:
> > INFO: vacuuming "pg_toast.pg_toast_106668498"
> > vacuumdb: vacuuming of database "etsy_v2" failed: ERROR: could not access status of transaction 3429738606
> > DETAIL: Could not open file "pg_clog/0CC6": No such file or directory.
I don't understand the pg_upgrade code here. It is setting the
datfrozenxid and relfrozenxid values to the latest checkpoint's NextXID,
/* set pg_class.relfrozenxid */
PQclear(executeQueryOrDie(conn,
"UPDATE pg_catalog.pg_class "
"SET relfrozenxid = '%u' "
/* only heap and TOAST are vacuumed */
"WHERE relkind IN ('r', 't')",
old_cluster.controldata.chkpnt_nxtxid));
but I don't see why this is safe. I mean, surely the previous
vacuum might have been a lot earlier than that. Are these values reset
to more correct values (i.e. older ones) later somehow? My question is,
why isn't the new cluster completely screwed?
I wonder if pg_upgrade shouldn't be doing the conservative thing here,
which AFAICT would be to set all frozenxid values as furthest in the
past as possible (without causing a shutdown-due-to-wraparound, and
maybe without causing autovacuum to enter emergency mode either).
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Martín Marqués | 2011-08-29 18:52:12 | Re: passing cursors from one PL function to another |
Previous Message | Pavel Stehule | 2011-08-29 18:28:11 | Re: passing cursors from one PL function to another |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-08-29 18:41:49 | Re: spinlocks on HP-UX |
Previous Message | Robert Haas | 2011-08-29 18:32:49 | Re: spinlocks on HP-UX |