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.
FYI, we do freeze the new cluster that has only schema definitions, no data. > 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 ... Yea, I can fix that in PG 8.4.1, but that doesn't seem like the cause of the missing rows. Alvaro and I are still investigating. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
