From: | Jamie Fox <jfox(at)directcommerce(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] large object does not exist after pg_migrator |
Date: | 2009-07-14 19:54:15 |
Message-ID: | de22a6520907141254m2d46e374w8e0dbb7af91aba42@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
> > 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.
Thanks,
Jamie
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2009-07-14 19:58:11 | Re: [Q] single image Table across multiple PG servers |
Previous Message | Greg Sabino Mullane | 2009-07-14 19:53:12 | Re: [Q] single image Table across multiple PG servers |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-07-14 20:17:47 | navigation menu for documents |
Previous Message | Tom Lane | 2009-07-14 19:50:06 | Re: more than one index in a single heap pass? |