[ADMIN] Kernel 2.4->2.6 upgrade results in PANIC: could not locate a valid checkpoint record

2006-04-14 Thread Achilleus Mantzios
Hi, we have happily been running postgresql 7.4.x (currently 7.4.12) on a debian linux with kernel 2.4.x for some years without any issues. Yesterday after switching to 2.6.16 we experienced the following problem upon pgsql startup: LOG: could not open file "/var/lib/pgsql/data/pg_xlog/0069

Re: [ADMIN] Kernel 2.4->2.6 upgrade results in PANIC: could not locate a

2006-04-14 Thread Achilleus Mantzios
Problem solved. The sysadmins yesterday forgot to mention to me that they didnt mount correctly all the file systems (including the one of pg_xlog). Sorry for the noise :-) O Achilleus Mantzios έγραψε στις Apr 14, 2006 : > > Hi, we have happily been running postgresql 7.4.x (currently 7.4.12)

[ADMIN] what the problem with this query

2006-04-14 Thread venu gopal
Hi all,   When i try to run the following query it gives the following error what was wrong in the query.Query:SELECT o.orgunitname AS ouname, e.entrynumber AS value_field, centroid(c.the_geom) AS the_geom, c.ogc_fid AS ogc_fid FROM (ctrphc AS c INNER JOIN orgunit o ON c.dhs_ouname = o.orgunitname)

Re: [ADMIN] what the problem with this query

2006-04-14 Thread Guido Barosio
o.orgunitid = e.orgunitid) That ")" is not valid Venu. (Nothing is being enclosed) Regards, Guido On 4/14/06, venu gopal <[EMAIL PROTECTED]> wrote: > > Hi all, >When i try to run the following query it gives the following error what > was wrong in the query. > > Query:SELECT o.orgunitname A

Re: [ADMIN] [GENERAL] what the problem with this query

2006-04-14 Thread William Penberthy
IT appears you have one too many closing parans…   SELECT o.orgunitname AS ouname, e.entrynumber AS value_field, centroid ( c.the_geom )   AS the_geom, c.ogc_fid AS ogc_fid FROM ( ctrphc AS c INNER JOIN orgunit o ON c.dhs_ouname = o.orgunitname )   INNER JOIN (   

[ADMIN] Slony1 or DRBD for replication ?

2006-04-14 Thread Pierre LEBRECH
Hello, I want to replicate my PostgreSQL database at an other location. The distance between the two locations should be around 10 miles. The link should be a fast ethernet dedicated link. What would you suggest me to do? DRBD or slony1 for PostgreSQL replication? Thank you. ---

Re: [ADMIN] Slony1 or DRBD for replication ?

2006-04-14 Thread Shoaib Mir
SLONY should be the choice :)On 4/14/06, Pierre LEBRECH <[EMAIL PROTECTED]> wrote: Hello,I want to replicate my PostgreSQL database at an other location. Thedistance between the two locations should be around 10 miles. The link should be a fast ethernet dedicated link.What would you suggest me to d

Re: [ADMIN] Slony1 or DRBD for replication ?

2006-04-14 Thread Joshua D. Drake
On Fri, 2006-04-14 at 14:56 +0200, Pierre LEBRECH wrote: > Hello, > > I want to replicate my PostgreSQL database at an other location. The > distance between the two locations should be around 10 miles. The link > should be a fast ethernet dedicated link. > > What would you suggest me to do? DRBD

Re: [ADMIN] Slony1 or DRBD for replication ?

2006-04-14 Thread Pierre LEBRECH
Joshua D. Drake wrote: > On Fri, 2006-04-14 at 14:56 +0200, Pierre LEBRECH wrote: > >>Hello, >> >>I want to replicate my PostgreSQL database at an other location. The >>distance between the two locations should be around 10 miles. The link >>should be a fast ethernet dedicated link. >> >>What woul

Re: [ADMIN] Slony1 or DRBD for replication ?

2006-04-14 Thread Christopher Browne
In the last exciting episode, [EMAIL PROTECTED] (Pierre LEBRECH) wrote: > Thanks for any suggestions and explanations. A third possibility would be PITR, new in version 8, if the point is to have recovery from big failure. You'd periodically copy the whole DB, and continually copy WAL files acros

Re: [ADMIN] Autovacuum ideas

2006-04-14 Thread Andy Shellam
The problem is the PG team are looking at making autovac compulsory (ie. You can't turn it off). I don't know when, might be in 8.2, but I know the issue has been discussed on the lists before. Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua

Re: [ADMIN] Autovacuum ideas

2006-04-14 Thread Brendan Duddridge
I guess I was thinking that if you do a vacuum analyze verbose from within psql, it does vacuum the big 'insert only' tables. Of course it never finds any dead rows, but it does take a long time to get past those tables. I didn't know that autovacuum would be any different.