Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] large object does not exist after pg_migrator

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Jamie Fox <jfox(at)directcommerce(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] large object does not exist after pg_migrator
Date: 2009-07-20 22:06:57
Message-ID: 200907202206.n6KM6vA08805@momjian.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
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
TODO item.

This eliminates the last known bug in pg_migrator.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

Attachment: /rtmp/diff
Description: text/x-diff (6.3 KB)

In response to

pgsql-hackers by date

Next:From: Jaime CasanovaDate: 2009-07-20 22:15:12
Subject: Re: fix: plpgsql: return query and dropped columns problem
Previous:From: Greg StarkDate: 2009-07-20 21:40:30
Subject: Re: [PATCH] SE-PgSQL/tiny rev.2193

pgsql-general by date

Next:From: APseudoUtopiaDate: 2009-07-20 22:23:23
Subject: Server Backup: pg_dump vs pg_dumpall
Previous:From: Bruce MomjianDate: 2009-07-20 20:55:07
Subject: Re: [GENERAL] large object does not exist after pg_migrator

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group