On Mon, Jul 13, 2009 at 8:03 PM, Bruce Momjian <br...@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
