Re: pg_dump after transaction id wraparound failure

> And I just demonstrated it on a test 7.4.7 database here (Debian
> 7.4.7-6 to be precise).
>
> test=# select ctid, xmin, xmax, cmin, cmax, * from test;
> ctid | xmin | xmax | cmin | cmax | x
> -------+------------+------+------+------+---
> (0,1) | 541 | 0 | 0 | 0 | 1
> (0,2) | 2147484153 | 0 | 0 | 0 | 2
> (0,3) | 2147484183 | 0 | 0 | 0 | 3
> (3 rows)
>
> ### Row is still there...
>
> test=# select ctid, xmin, xmax, cmin, cmax, * from test;
> ctid | xmin | xmax | cmin | cmax | x
> -------+------------+------+------+------+---
> (0,2) | 2147484153 | 0 | 0 | 0 | 2
> (0,3) | 2147484183 | 0 | 0 | 0 | 3
> (2 rows)
>
> ### OMG, row is gone
>
> test=# vacuum test;
> VACUUM
> test=# select ctid, xmin, xmax, cmin, cmax, * from test;
> ctid | xmin | xmax | cmin | cmax | x
> -------+------------+------+------+------+---
> (0,1) | 2 | 0 | 0 | 0 | 1
> (0,2) | 2147484153 | 0 | 0 | 0 | 2
> (0,3) | 2147484183 | 0 | 0 | 0 | 3
> (3 rows)
>
> ### Yay row is back
> test=# select version();
> version
> -------------------------------------------------------------------------------------------------------
> PostgreSQL 7.4.7 on i386-pc-linux-gnu, compiled by GCC i386-linux-gcc (GCC) 3.3.5 (Debian 1:3.3.5-12)
> (1 row)
>
> Have a ncie day,
> --
To Clarify - So the consensus is to vacuum the entire database? This
should take care of any possible loss of data. Then after this I
should pg_dump?

Thanks again
--Mike