Re: pg_upgrade - link mode and transaction-wraparound data loss

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: jesper(at)krogh(dot)cc
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_upgrade - link mode and transaction-wraparound data loss
Date: 2010-05-18 16:57:43
Message-ID: 201005181657.o4IGvhk05043@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

jesper(at)krogh(dot)cc wrote:
> Hi
>
> I tried running pg_upgrade from the current snapshot of postgresql and
> upgrading from 8.4.4 to the snapshot version. Everything seem to look fine
> in the process and all that came out was only "ok's" but when I tried a
> simple query on the databse it keeps throwing these message out of the back
> side.
>
> DETAIL: You might have already suffered transaction-wraparound data loss.
> WARNING: some databases have not been vacuumed in over 2 billion
> transactions
>
>
> The database was around 600GB and it took a couple of minutes to run
> pg_upgrade after I had all the binaries in the correct place.
>
> It is not really an easy task to throw around 600GB of data, so I cannot
> gaurantee that the above is reproducible, but I'll see if I can get time
> and try to reproduce it.

This certainly should never have happened, so I am guessing it is a bug.
pg_upgrade tries hard to make sure all your datfrozenxid and
relfrozenxid are properly migrated from the old server, and the
transaction id is set properly. Unfortunately this is the first time I
have heard of such a problem, so I am unclear on its cause.

The warning is issued from vacuum.c::vac_truncate_clog(). Can you run
this query and show us the output:

SELECT datname, datfrozenxid FROM pg_database;

It would be good to see these numbers on both the old and new servers.
I would also like to see:

SELECT txid_current();

on the old and new servers, but if you can only provide these values on
one of the two servers, it is still useful. Thanks.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tony Sullivan 2010-05-18 17:19:13 Unexpected data beyond EOF during heavy writes
Previous Message Stephen Frost 2010-05-18 16:49:02 Documentation Bug/Misnomer?