[GENERAL] Problem with a transaction on dump
Hello everyone, It is the second time i got this error message (sorry, its french, i prefer to c/p this one than making a bad translation) : ---88---8--- pg_dump: ERREUR: Impossible d'accéder au statut de la transaction 892415538 DETAIL: Impossible d'ouvrir le fichier «/var/lib/postgresql/7.4/main/pg_clog/0353» : Aucun fichier ou répertoire de ce type pg_dump: La commande SQL de sauvegarde du contenu de la table facture a échoué : échec de PQendcopy(). pg_dump: Message d'erreur du serveur : ERREUR: Impossible d'accéder au statut de la transaction 892415538 DETAIL: Impossible d'ouvrir le fichier «/var/lib/postgresql/7.4/main/pg_clog/0353» : Aucun fichier ou répertoire de ce type pg_dump: La commande était : COPY public.facture ([...]) TO stdout; ---88---8--- It say that it cant access to the transaction id 892415538 because the file /var/lib/postgresql/7.4/main/pg_clog/0353 dont exist. And this file doesn't exist. I use PG 7.4.16 on linux debian etch. I already made a HD memory test, and i find nothing wrong. Last time i got this error, the only solution was to get a safe backup and lost some data. But i didnt have time to manage this server, so this error is here for a couple of day, and im afraid about how many data may be lost. So if someone have an idea to have a safe backup and start on a clean database... Thx in advance, Regards, ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Problem with a transaction on dump
Alvaro Herrera wrote: Froggy / Froggy Corp. wrote: Hello everyone, It is the second time i got this error message (sorry, its french, i prefer to c/p this one than making a bad translation) : ---88---8--- pg_dump: ERREUR: Impossible d'accéder au statut de la transaction 892415538 DETAIL: Impossible d'ouvrir le fichier «/var/lib/postgresql/7.4/main/pg_clog/0353» : Aucun fichier ou répertoire de ce type What files are there in main/pg_clog? to 0024 888 -rw--- 1 postgres postgres 262144 Jul 25 2006 -rw--- 1 postgres postgres 262144 Jul 28 2006 0001 -rw--- 1 postgres postgres 262144 Aug 5 2006 0002 -rw--- 1 postgres postgres 262144 Aug 13 2006 0003 -rw--- 1 postgres postgres 262144 Aug 22 2006 0004 -rw--- 1 postgres postgres 262144 Aug 28 2006 0005 -rw--- 1 postgres postgres 262144 Sep 4 2006 0006 -rw--- 1 postgres postgres 262144 Sep 10 2006 0007 -rw--- 1 postgres postgres 262144 Sep 17 2006 0008 -rw--- 1 postgres postgres 262144 Sep 25 2006 0009 -rw--- 1 postgres postgres 262144 Oct 2 2006 000A -rw--- 1 postgres postgres 262144 Oct 9 19:50 000B -rw--- 1 postgres postgres 262144 Oct 17 06:04 000C -rw--- 1 postgres postgres 262144 Oct 25 11:13 000D -rw--- 1 postgres postgres 262144 Nov 2 12:44 000E -rw--- 1 postgres postgres 262144 Nov 8 21:41 000F -rw--- 1 postgres postgres 262144 Nov 16 10:03 0010 -rw--- 1 postgres postgres 262144 Nov 23 07:56 0011 -rw--- 1 postgres postgres 262144 Nov 29 22:48 0012 -rw--- 1 postgres postgres 262144 Dec 6 16:36 0013 -rw--- 1 postgres postgres 262144 Dec 13 02:15 0014 -rw--- 1 postgres postgres 262144 Dec 19 15:57 0015 -rw--- 1 postgres postgres 262144 Dec 27 04:34 0016 -rw--- 1 postgres postgres 262144 Jan 2 22:14 0017 -rw--- 1 postgres postgres 262144 Jan 8 17:27 0018 -rw--- 1 postgres postgres 262144 Jan 17 16:02 0019 -rw--- 1 postgres postgres 262144 Jan 24 00:18 001A -rw--- 1 postgres postgres 262144 Jan 31 10:03 001B -rw--- 1 postgres postgres 262144 Feb 6 17:23 001C -rw--- 1 postgres postgres 262144 Feb 13 13:34 001D -rw--- 1 postgres postgres 262144 Feb 20 22:23 001E -rw--- 1 postgres postgres 262144 Feb 28 18:03 001F -rw--- 1 postgres postgres 262144 Mar 8 09:58 0020 -rw--- 1 postgres postgres 262144 Mar 16 15:07 0021 -rw--- 1 postgres postgres 262144 Mar 25 04:02 0022 -rw--- 1 postgres postgres 262144 Apr 2 14:21 0023 -rw--- 1 postgres postgres 81920 Apr 4 16:17 0024 -88--8-- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Problem with a transaction on dump
Alvaro Herrera wrote: Froggy / Froggy Corp. wrote: Alvaro Herrera wrote: Froggy / Froggy Corp. wrote: Hello everyone, It is the second time i got this error message (sorry, its french, i prefer to c/p this one than making a bad translation) : ---88---8--- pg_dump: ERREUR: Impossible d'accéder au statut de la transaction 892415538 DETAIL: Impossible d'ouvrir le fichier «/var/lib/postgresql/7.4/main/pg_clog/0353» : Aucun fichier ou répertoire de ce type What files are there in main/pg_clog? to 0024 FWIW, I examined the bit pattern in the number 892415538, which is 110101001100010010111000110010, and taken as octets interpreted as ASCII chars, they look like this: 51.2 So my guess is that your table was corrupted by the filesystem or something like that. Did your system crash recently? My guess is that this is a filesystem problem, kernel bug or something like that. Yep i got a crash before the first problem. But the dump run nicely until a day it crash with this kind of error. BTW, beetween, i put all data on a new (safe ?) database, and i dont have any kind of crash. Actually, do you know a way to get back a maximum of data ? I have a particular thing : i have one dump with 13MB and other are 5MB. I dont really understand the exact error message. That mean that on a transaction, the DB crash (or something like that), so i have an INSERT/UPDATE or something like that which is lost, but other data are not corrupted ? Or it is an index which is corrupted, so more data are corrupted too ? ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[GENERAL] [PL/PGSQL] (Bug/Feature problem) with recursive Trigger
Hello,
I got some problem on trigger which call them self for UPDATE
BEFORE/AFTER.
Here is some test :
The UPDATE test function/table :
--888--
CREATE SEQUENCE id_my_table_seq;
CREATE table my_table (
id_my_table int4 DEFAULT nextval('id_my_table_seq') PRIMARY KEY,
row0 text,
row1 text,
row2 text
);
INSERT INTO my_table (id_my_table, row0, row1, row2) VALUES (10,
'data0', 'data1', 'data2');
CREATE OR REPLACE FUNCTION my_table_before_update() RETURNS trigger AS '
DECLARE
BEGIN
IF OLD.row0 NEW.row0 THEN
RAISE NOTICE ''test1 %'', OLD.row0;
RAISE NOTICE ''test2 %'', NEW.row0;
UPDATE my_table SET row1 = \'toto\' WHERE id_my_table =
NEW.id_my_table;
RAISE NOTICE ''test3 %'', OLD.row0;
RAISE NOTICE ''test4 %'', NEW.row0;
UPDATE my_table SET row1 = \'tata\' WHERE id_my_table =
NEW.id_my_table;
RAISE NOTICE ''test5 %'', OLD.row0;
RAISE NOTICE ''test6 %'', NEW.row0;
END IF;
RETURN NEW;
END;
' LANGUAGE plpgsql;
CREATE TRIGGER my_table_before_update BEFORE UPDATE ON my_table FOR EACH
ROW EXECUTE PROCEDURE my_table_before_update();
CREATE OR REPLACE FUNCTION my_table_after_update() RETURNS trigger AS '
DECLARE
BEGIN
RAISE NOTICE ''test7 %'', OLD.row0;
RAISE NOTICE ''test8 %'', NEW.row0;
RETURN NEW;
END;
' LANGUAGE plpgsql;
CREATE TRIGGER my_table_after_update AFTER UPDATE ON my_table FOR EACH
ROW EXECUTE PROCEDURE my_table_after_update();
--888--
The test for these trigger :
UPDATE my_table set row0 = 'my_test' WHERE id_my_table = 10;
Result :
On a 7.4.7 :
UPDATE my_table set row0 = 'my_test' WHERE id_my_table = 10;
NOTICE: test1 data0
NOTICE: test2 my_test
NOTICE: test3 data0
NOTICE: test4 my_test
NOTICE: test5 data0
NOTICE: test6 my_test
NOTICE: test7 data0
NOTICE: test8 data0
NOTICE: test7 data0
NOTICE: test8 data0
on a 8.1.4 (without context) :
test=# update my_table set row0 = 'my_test' WHERE id_my_table = 10;
NOTICE: test1 data0
NOTICE: test2 my_test
NOTICE: test7 data0
NOTICE: test8 data0
NOTICE: test3 data0
NOTICE: test4 my_test
NOTICE: test7 data0
NOTICE: test8 data0
NOTICE: test5 data0
NOTICE: test6 my_test
PG7 dont make recursiv, it wait for the end of the trigger BEFORE_UPDATE
to call the new UPDATE stat and forgot the 3rd AFTER_UPDATE. PG8 is
better, it call trigger like real recursiv fonction, but allways dismiss
the 3rd AFTER UPDATE.
Logically, the answer should be :
NOTICE: test1 data0
NOTICE: test2 my_test
NOTICE: test7 data0
NOTICE: test8 data0
NOTICE: test3 data0
NOTICE: test4 my_test
NOTICE: test7 data0
NOTICE: test8 data0
NOTICE: test5 data0
NOTICE: test6 my_test
NOTICE: test7 data0
NOTICE: test8 my_test
At beginning, i made a test to see how pl/pgsql make real recursiv with
an insert function which work :
---8---8---8---8---
CREATE SEQUENCE id_test_seq;
CREATE table test (
id_test int4 DEFAULT nextval(id_test_seq) PRIMARY KEY,
test text,
other_row text,
);
CREATE OR REPLACE FUNCTION test_insert() RETURNS trigger AS '
DECLARE
categorie_mere RECORD;
categorie_mere_lien RECORD;
RecTmp RECORD;
BEGIN
RAISE NOTICE ''begginning'';
IF NEW.test = ''test'' THEN
INSERT INTO test (test) VALUES (''toto'');
END IF;
RAISE NOTICE ''end'';
RETURN NEW;
END;
' LANGUAGE plpgsql;
CREATE TRIGGER test_insert BEFORE INSERT ON test FOR EACH ROW EXECUTE
PROCEDURE test_insert();
---8---8---8---8---
With a :
INSERT INTO test (test) values ('test');
You obtain in each case :
NOTICE: begginning
NOTICE: begginning
NOTICE: end
NOTICE: end
-
In fact, what i dont understand, its why PG dont forget to make the 2
update inside the main update, but after, forgot to make the last one.
Any idea ?
Regards,
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [GENERAL] [PL/PGSQL] (Bug/Feature problem) with recursive Trigger
Tom Lane wrote: Froggy / Froggy Corp. [EMAIL PROTECTED] writes: PG7 dont make recursiv, it wait for the end of the trigger BEFORE_UPDATE to call the new UPDATE stat and forgot the 3rd AFTER_UPDATE. PG8 is better, it call trigger like real recursiv fonction, but allways dismiss the 3rd AFTER UPDATE. There isn't any third AFTER UPDATE because the updates fired by the trigger override the pending update, and so when the trigger returns the pending update is abandoned. This is a really badly designed trigger anyway: why don't you just modify the NEW row, instead of incurring orders of magnitude more work by launching an entire new SQL command? I make some reorganization of my table when user make an update. The trigger need to be able to support lot of case, so to make reorganization more simple, i make some test, and change or make change of this table by other part of trigger which are on after_update or before_update. Because the trigger call itself, this way is more easy and decrease considerably all possibility. In fact, i thought that for recursiv trigger, PG alocate a new trigger in memory, so it should not be a problem. I dont know if its really bad, but i dont see any more option to do it (btw, i will need to change these part to make trigger working). All trigger for this table work like that. Regards, ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] [PL/PGSQL] (Bug/Feature problem) with recursive Trigger
Its my plan in fact, it was to make some optimisation, because i need to copy all the test from the BEFORE statement to the AFTER. Thx for your help, Regards, Tom Lane wrote: Froggy / Froggy Corp. [EMAIL PROTECTED] writes: Tom Lane wrote: This is a really badly designed trigger anyway: why don't you just modify the NEW row, instead of incurring orders of magnitude more work by launching an entire new SQL command? I make some reorganization of my table when user make an update. The trigger need to be able to support lot of case, so to make reorganization more simple, i make some test, and change or make change of this table by other part of trigger which are on after_update or before_update. If you are cascading changes to other rows, you should do them in AFTER triggers. It's not really very sensible to try to do that in a BEFORE trigger, because a BEFORE trigger shouldn't assume it's seeing the final version of the row. BEFORE triggers are good for checking or adjusting the data in the proposed new row, but for pushing consequences out to other rows, use an AFTER trigger. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[GENERAL] Report of some problem under PL/PGSQL 7.4.7 8.0.1
Hi everyone,
I made a tetris under pl/pgsql and i encounter some problem with this
non commun use of pl/pgsql. For each problem, i didn't see information
about them, so my report :
- Array problem (7.4.7 8.0.1) :
I got a lot of problem with using array, like i saw under the ML,
multidimensional array are not friendly to use so i used 1 dimension
array but i needed to put data at point (x,y).
The problem is how the array is created and how i can put data into it.
I use this little test function :
--
CREATE OR REPLACE FUNCTION test_array() RETURNS integer AS '
DECLARE
a integer;
b integer;
c integer;
array varchar[];
BEGIN
array := ''{}'';
a := 1;
WHILE a 17 LOOP
b := 1;
WHILE b 17 LOOP
c:= a + b * 16;
RAISE NOTICE ''%'', c;
array[c] := ;
b := b + 1;
END LOOP;
a := a + 1;
END LOOP;
return 0;
END;
' LANGUAGE plpgsql;
Error message :
tetris=# select test_array();
NOTICE: 17
NOTICE: 33
ERROR: invalid array subscripts
CONTEXT: PL/pgSQL function test_array line 16 at assignment
To correct this error message, i need to make 2 init, the first with
array := ''{}''; and a second one by insert data into it with
incremential pointer :
a := 0;
WHILE a = 999 LOOP
array[a] := '' '';
END LOOP;
Then my function test_array() work properly.
But i dont understand why PL allow me to assign 2 times data into my
array with random pointer and not the 3rd times.
BTW, i dont really understand why i need to make array := ''{}'';,
some people who test it from pgsqlfr-general ML try without making this
init and get not problem with random pointer. But array was null.
- Problem with table refresh
For my game, i need to detect keystroke, so i made an infinit loop
waiting for key to be press.
I have two case for 7.4.7 8.0.1, under 8.0.1 it seems to work
properly.
Under 7.4.7, i need to make :
WHILE a = 0 LOOP
for rGetkey IN SELECT * FROM getkey LOOP
a := 1;
END LOOP;
select into a count(key) FROM getkey;
END LOOP;
Or i will allways have a = 0 (maybe i miss something).
But under 8.0.1, its ok with :
WHILE a = 0 LOOP
select into a count(key) FROM getkey;
END LOOP;
- Some features :
I was surprise to see that i cant put any ' after --. I thought it was
detect as comment, so all after it on the line will not be compile
Same as table refresh, i didnt understand why the function now() (7.4.7
8.0.1) dont refresh it self under a PL function and needed to use
timeofday();
The test function :
--
CREATE OR REPLACE FUNCTION test_now() RETURNS varchar AS '
DECLARE
a timestamp;
b integer;
BEGIN
b := 1;
while b 0 LOOP
select into a now();
RAISE NOTICE ''%'', a;
END LOOP;
return ''a'';
END;
' LANGUAGE plpgsql;
--
That's all,
Regards,
---(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
Re: [GENERAL] [pgsql-fr-generale] Problème de threadPostgresql
Dénouement : J'ai enfin trouvé toutes les réponses à mes questions via la comande REINDEX. Merci à Jean-Christophe Arnu (s'il passe par ici) qui a confirmé via son article sur http://www.postgresqlfr.org/?q=node/view/49 la solution que j'avais cherché depuis quelques temps. Froggy / Froggy Corp. wrote: Le serveur actuelle ayant que 256Mo de RAM, j avais supprimé il y a plusieurs mois les connexions persistantes. Mais en pratique, après une petite gaffe de ma part, j avais un très bon load, et ceci en connexion non persistantes. Actuellement, je n'utilise plus de connexion persistantes. Mais au final je me demande si ce n'ai pas juste un problème de tuning car après la suppression/restauration d'une table utilisateur, j etais passé d'un load de 3-4 à moins de 1. Daniel Verite wrote: Froggy / Froggy Corp. writes l'id du thread change constement, donc le serveur kill/créé un log à chaque affichage de page pratiquement. Le même test a été effectué sur un serveur de test, et là je me retrouve bien avec x threads postgres. Vérifier les paramètres pgsql.allow_persistent et pgsql.max_persistent du fichier php.ini, à supposer que les connexions soient faites avec pg_pconnect() ? PS: il ne s'agit pas de threads mais de processus, postgresql n'utilisant pas les threads. -- Daniel PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[GENERAL] [Fwd: Re: [pgsql-fr-generale] Décision Micro ?]
---BeginMessage--- Il me parait un peu illusoire de contester un test alors que CleverAge a pris la peine de contacter la communauté francophone de PostgreSQL et que personne ne s'est déplacée (pour des raisons que je ne critique pas). Donc à partir de ce moment là, je trouve abhérant de contester l'article et/ou les résultats. Je reviendrais sur quelques points qui ont été critiqué précédement : - Version Windows : La fin de l'article précise qu'une version Windows est prévue. Effectivement, PostgreSQL 7.x peut tourner sous Windows (avec le couple Cygwin/ipc) ou la version 8.x en natif. Mais ce sont des versions récentes ou en encore en développement et ne peuvent donc pas être prise en compte dans le test. - Problème d'installation : Effectivement, PostgreSQL n'ai pas une bdd simple à installer. Pour une bdd public (a contrario d'une bdd de dev), la gestion de droit (pour ne prendre que cette exemple), est relativement peu évident pour un novice. - Pas de sauvegarde/restauration : Le dump de la base de donnée (si il a été utilisé dans les tests) ne constitue pas le meilleur moyen de sauvegarde. Je n'ai que quelques 10e de milliers d'enregistrements, mais cela me prend une ou deux minutes à restaurer. Dans le cas de base avec plusieurs millions, la restauration de la bdd via un dump est à mon avie plus qu'ilusoir. Je pense que l'article parle de sauvegarde de l'architecture de la bdd, permettant une restauration dependant de la vitesse de lecture d'un DAT/DLT et non de la reconstruction totale de la bdd via un dump. Je prendrais l exemple de ArcServeIT qui stop les services pour effectuer la sauvegarde des BDDs, permetant une restauration rapide du systeme en cas de panne. Personnellement, après avoir lu le pdf, je le trouve effectivement léger par rapport à tout ce qui pourrait être dit sur postgresql (mais egalement sur les autres bdds) mais il reste techniquement tres correct pour son corps de cible (des utilisateurs non chevronnés dans tout ce qui est bdd). Je partage l'avis final sur Postgresql qui se réserve pour des administrateurs en herbe (ou non) chevronnées. Meme si je comprends l'ensemble des personnes qui auraient souhaité une meilleure note à leur produit fetiche, je pense qu'une lettre serait aussi inutile que discriminatoire. ---End Message--- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] PL/SQL question
Hello,
In fact the problem seems to come from the INSERT INTO. I delete
everything from the function and only keep the INSERT INTO and get the
same problem.
Thx in advance for answers,
regards,
Stephan Szabo wrote:
On Tue, 20 Apr 2004, Froggy / Froggy Corp. wrote:
I try to see if i can make a recursive function with a trigger set on
INSERT and doing an insert under my trigger function.
So i wrote a test function :
CREATE OR REPLACE FUNCTION testfunc() RETURNS SETOF RECORD AS '
DECLARE
use_t RECORD;
BEGIN
SELECT INTO use_t id_categorie FROM categorie ORDER BY id_categorie
DESC;
IF use_t.id_categorie50 THEN
INSERT INTO categorie (nom) VALUES (''test'');
END IF;
RETURN NULL;
END;
'LANGUAGE plpgsql;
The problem is that i can't exec this function to test it, psql return
the following error :
ERROR: set-valued function called in context that cannot accept a set
Record set returning functions aren't called as:
select foo();
but instead as
select * from foo() AS foo(columns);
However, since you're not apparently actually returning a set of anything
in the function you may just want to change the return type.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[GENERAL] PL/SQL question
Hello everyone,
I try to see if i can make a recursive function with a trigger set on
INSERT and doing an insert under my trigger function.
So i wrote a test function :
CREATE OR REPLACE FUNCTION testfunc() RETURNS SETOF RECORD AS '
DECLARE
use_t RECORD;
BEGIN
SELECT INTO use_t id_categorie FROM categorie ORDER BY id_categorie
DESC;
IF use_t.id_categorie50 THEN
INSERT INTO categorie (nom) VALUES (''test'');
END IF;
RETURN NULL;
END;
'LANGUAGE plpgsql;
The problem is that i can't exec this function to test it, psql return
the following error :
ERROR: set-valued function called in context that cannot accept a set
But my INSERT INTO works if i write it directly.
Someone get an idea ?
Thx in advance,
regards,
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[GENERAL] Postgresql 7.4.1 - Template database and user permission
Hello, I'am using postgresql to make different web site with differente database for each, but with same table/link/... So, i change from 7.2 to 7.4 and try to use template function to create each new DB more easier (with user posgres): CREATE DATABASE myowntemplate TEMPLATE = template1; After that, i create the differentes tables. I create my user and create the db for each user : CREATE DATABASE user_db OWNER = user TEMPLATE = myowntemplate; Update data, and try it. But i got a msg in the postgresql.log that my user have not the permission to access the tables : ERROR: permission denied for relation table1 ERROR: permission denied for relation table2 [...] So maybe i made a mistake, by i thought by making user the owner of user_db, he will gain each priviliges on myowndb. Thanx for answers, regards, ---(end of broadcast)--- TIP 8: explain analyze is your friend
[GENERAL] Using of GeQo
Hello (again), I read some documentation about tuning postgresql.conf but i didn't find information clearly about how to use GeQo. It seems to help planner but using a lot of CPU, and is usefull only for big join. Per default, geqo = true, but in which case, geqo is usefull and in which case, i will lost a lot of CPU ? If someone have some documentation or help about that. Thanks in advande, regards, ---(end of broadcast)--- TIP 8: explain analyze is your friend
[GENERAL] Need help with postgresql/apache/php optimisation
Hello, I asked one time for more benchmark soft to know where is the cpu average, and read the post about optimising the postgresql.conf (and use them), but i allways get a load 1 on fire time (dunno the right name, coup de feu in french (10h00 - 14h00, 18h00 - 21h00). For information, i have a Celeron 1.2Ghz with 256Mb, IDE drive, enough bandewitch, and about 3000 hit per day. Its postgresql 7.2.lastone, apache 1.3.lastone, linux (redhat), and the last 2.4 kernel after the exploit problem. Its not 'my' server, so i cant upgrade anything of it (RAM is very short i think). Im hosting a web site with apache/php. The table are not huge, the biggest is aroung 3000rows and only 25-30 tables. The problem is that on fire time, the load go to 1 and stay long time. But with top (i use top -d 1 to have real load average) i can see that the CPU is more than 50% idling. For exemple, i have this kind of stat : 0s - load 1.5 - cpu idling 0% 5s - load 1.6 - cpu ilding 50% 6s - 60s - load around 1.2 - cpu idling around 50%-100% (Dunno if its very easy to understand). With different software, i dont see anything wrong (or i dont understand how to use them), the problem is the memory which make some nice road around 12Mo Free and 3Mo Free, but the swap dont really grow up (but linux make a lot of cache). In fact, i hosted the old site with mysql/apache and i was very happy to see the load going from 0.90 to 0.40 but the population growing up and the problem came. I made the common optimisation with VACUUM ANALYZE and some from the documentation. Maybe i dont understand what load average mean, but i dont understand why with more than 50% cpu idling, the load average dont grow down. So i thought i lose cpu from somewhere ... but the probleme is what is this somewhere :). If someone could help me, i need to put a new feature which will add more than 2000 hit per day and im afraid about the life of the server :). Really thx in advance, regards, ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
