On Mon, 27 Dec 2004, Peter Childs wrote:
> Tom Lane wrote:
>
> >Peter Childs <blue.dragon@blueyonder.co.uk> writes:
> >
> >
> >>2. I loaded out 7.4 database on via a dump and reload. Once done I keep
> >>getting errors when it trys to analyse (I'm using autovacuum) Nothing
> >>unsuall just a straght forward pg_dump from 7.4 loaded into 8.0.
> >>
> >>
> >
> >
> >
> >>Dec 27 07:34:45 ex37 postgres[5745]: [28-1] ERROR: could not access
> >>status of transaction 2684354560
> >>
> >>
> >
> >Is this repeatable if you start over (re-initdb and reload)? If so I'd
> >be very interested to see the dump file.
> >
> > regards, tom lane
> >
> >
> >
> I've dumped twice and reloaded twice same problem both times. Its
> difficult to let you see the dump as due to Data Protection. I re-inited
> once and reloaded just to check. I'll try a dump without data and see if
> that causes the same problem If that fails I'll can send you that. Then
> I might try adding data for tables that are not a risk.
> I'll do it tomarrow now, as I'm off as my Wife had a baby yestarday.
>
> Peter Childs
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
>
Further examination.... I orignally used by 7.4 backup (taken
every 12 hours and well tested that they work under 7.4 anyway) rather
than redumping using pg_dump 8.0. I have now dumped using pg_dump version
8.0 same problem. I dumped just the schema. upon load into 8.0 a couple of
lines saying
ERROR: relation "test_id_seq" does not exist
STATEMENT: REVOKE ALL ON TABLE shopping_id_seq TO PUBLIC;
ERROR: relation "test_id_seq" does not exist
STATEMENT: GRANT ALL ON TABLE test_id_seq TO PUBLIC;
Not that important but no problem with the empty database but then
its empty!
Since the dumps are just sql right? I'm guessing that this has to
be some internal problem.
Peter Childs
