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