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 p
Bruce Momjian wrote:
> > 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 m
Worked great, vacuumlo finished, a vacuum -full finished amazingly quickly,
very exciting. We're pointing qa apps at it now for testing.
For some reason though, that index has to be rebuilt after running
pg_migrator.
I'll be testing on our 100GB+ prod copy shortly and will let you know if you
wan
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 did it work?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreS
> > 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
On Mon, Jul 13, 2009 at 8:03 PM, Bruce Momjian 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
> > > > > >
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 retur
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
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
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_m
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 180
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
Forwarded to hackers.
---
Jamie Fox wrote:
> Hi -
> This is probably more helpful - the pg_largeobject table only changed after
> vacuumlo, not before. When comparing pre- and post- pg_migrator databases
> (no vacuum or vac
Jamie Fox wrote:
> Hi -
> After what seemed to be a normal successful pg_migrator migration from 8.3.7
> to 8.4.0, in either link or copy mode, vacuumlo fails on both our production
> and qa databases:
>
> Jul 1 11:17:03 db2 postgres[9321]: [14-1] LOG: duration: 175.563 ms
> statement: DELETE F
14 matches
Mail list logo
