I regret that as a part-timer recently brought back on here I didn't get an opportunity to test this earlier. The upgrade with the patch worked fine on my first attempt. Thanks again, Jamie On Wed, Sep 28, 2011 at 7:32 PM, Bruce Momjian br...@momjian.us wrote: Jamie Fox wrote: Thanks, I'm
Thanks, I'm following the thread pg_upgrade automatic testing and will try the patch just detailed there. Jamie On Wed, Sep 28, 2011 at 12:50 AM, Peter Eisentraut pete...@gmx.net wrote: On tis, 2011-09-27 at 16:19 -0700, Jamie Fox wrote: It fails at this stage: Restoring user relation
Hi - I've had no problem upgrading copies our qa databases (which are backed up and restored with pg_dump/pg_restore) but have run into the same problem each time I try to upgrade a copy of our production database (backed up and restored via PITR). After verifying a successful restore and
want. Thanks, Jamie On Wed, Jul 15, 2009 at 9:28 AM, Alvaro Herrera alvhe...@commandprompt.comwrote: Jamie Fox wrote: 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. So
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
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.