On Mon, Jul 13, 2009 at 8:03 PM, Bruce Momjian
<bruce@momjian.us> wrote:
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > > Jamie Fox wrote:
> > >
> > > > > I can also see that the pg_largeobject table is different, in the pg_restore
> > > > > version the Rows (estimated) is 316286 and Rows (counted) is the same, in
> > > > > the pg_migrator version the Rows (counted) is only 180507.
> > >
> > > > Wow, I didn't test large objects specifically, and I am confused why
> > > > there would be a count discrepancy. I will need to do some research
> > > > unless someone else can guess about the cause.
> > >
> > > Maybe pg_largeobject is not getting frozen?
> >
> > That would explain the change in count, but I thought we froze
> > _everything_, and had to.
>
> After a quick chat with Bruce it was determined that we don't freeze
> anything (it would be horrid for downtime if we did so in pg_migrator;
> and it would be useless if ran anywhere else). What we do is migrate
> pg_clog from the old cluster to the new. So never mind that hypothesis.
>
> Bruce noticed that the pg_dump/pg_migrator combo is failing to restore
> pg_largeobject's relfrozenxid. We're not sure how this is causing the
> errors Jamie is seeing, because what I think should happen is that scans
> of the table should fail with failures to open pg_clog files
> such-and-such, but not missing tuples ...
Jamie, is it possible for you to apply the attached patch to the 8.4
server, install the new pg_dump, and run the test again to see if
pg_largeobject is fixed? This patch properly sets the relfrozenxid in
the system tables for each database.
Sorry for the confusion, an addendum meant to be helpful fell out of this thread during the move from -general. I will try this patch now, but to be clear - the number of rows in pg_largeobject changed after I ran vacuumlo (that eventually failed).
Here's what I have found that got broken during pg_migrate: In two side by side databases (an 8.3.7 copy and 8.4.0 migrated with pg_migrator) the pg_largeobject table has the same number of rows. However, in the 8.4 database any select for an loid in pg_largeobject returns zero rows. If I select all loids to a file, and compare to select all loids from 8.3.7 they're the same. When I select != an loid it seems to exclude the one and return the rest, but all other comparisons <, > or = return zero rows. Or I'm completely batty. Dereferencing via lo_open of blob_data (an oid) in other tables fails in the 8.4 database with 'large object xxxxid does not exist'.
Thanks again,
Jamie
