Jamie Fox wrote:
> > > 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'.
> > Oh, so maybe it's pg_largeobject's index that's borked ... Did you try
> > reindexing it?
> > How are we transferring pg_largeobject, and are we transferring its
> > index too?
> Hi -
> REINDEX INDEX pg_largeobject_loid_pn_index;
> This seems to have fixed the problem, lo_open of lob data is working again -
> now to see how vacuumlo likes it.
I have applied the attached patch to pg_migrator to properly migrate the
pg_largeobject index. I have added large object comment migration as a
This eliminates the last known bug in pg_migrator.
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
+ If your life is a hard drive, Christ can be your backup. +
Description: text/x-diff (6.3 KB)
In response to
pgsql-hackers by date
|Next:||From: Jaime Casanova||Date: 2009-07-20 22:15:12|
|Subject: Re: fix: plpgsql: return query and dropped columns problem|
|Previous:||From: Greg Stark||Date: 2009-07-20 21:40:30|
|Subject: Re: [PATCH] SE-PgSQL/tiny rev.2193|
pgsql-general by date
|Next:||From: APseudoUtopia||Date: 2009-07-20 22:23:23|
|Subject: Server Backup: pg_dump vs pg_dumpall|
|Previous:||From: Bruce Momjian||Date: 2009-07-20 20:55:07|
|Subject: Re: [GENERAL] large object does not exist after