Thread: 8.0 rc2 Problem
Right just installed rc2 to test so that we can use 8.0 once its
out. Loads of nice features, Nice to see them all. Postgres 8.0 seams
faster, but this might be due to the reload. Oh the point in time
recovery feature are there any example scripts to say copy the files to
somewhere then print them onto cd or somthing once created. Oh and is it
possible to examin the point in time logs and see what happerened when,
ie which table got updated to what, very useful when research problems
later.... Probably would require some form of viewer I guess.
2 Problems encountered.
1. Confirguration file is completly different, so it you have one that
you have configured carfull for 7.4 it will not work at all with 8.0
many configuration options have changed there names or changed how they
work. I can understand new ones and dropping some of the old ones but
why change it so complely?
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
Dec 27 07:34:45 ex37 postgres[5745]: [28-2] DETAIL: could not open file
"/data/db/pg_clog/0A00": No such file or directory
Dec 27 07:34:45 ex37 postgres[5745]: [28-3] STATEMENT: ANALYZE
"public"."driverworklog"
This is running on an almost new install of Debian Sarge.
Peter Childs
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
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
Peter Childs wrote: > Right just installed rc2 to test so that we can use 8.0 once its > out. Loads of nice features, Nice to see them all. Postgres 8.0 seams > faster, but this might be due to the reload. Oh the point in time > recovery feature are there any example scripts to say copy the files to > somewhere then print them onto cd or somthing once created. Oh and is it > possible to examin the point in time logs and see what happerened when, > ie which table got updated to what, very useful when research problems > later.... Probably would require some form of viewer I guess. > > 2 Problems encountered. > > 1. Confirguration file is completly different, so it you have one that > you have configured carfull for 7.4 it will not work at all with 8.0 > many configuration options have changed there names or changed how they > work. I can understand new ones and dropping some of the old ones but > why change it so complely? I would diff postgresql.conf against the share/postgresql.conf.sample and merge your changes into 8.0. We change it dramatically because we improve functionality and clarity. If we emphasized backward-compatibility it would be very unclear after a while. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
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
Peter Childs <blue.dragon@blueyonder.co.uk> writes:
> 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;
Could you send me that dump off-list?
regards, tom lane