Re: [ADMIN] problem on table statistics
There was a table set statistics changing the default value, now I remove and run analyze the stats are update correctly but the problem of different plan still stand. I set enable_nestloop off and the query plan is the following, the query is fast now: Hash IN Join (cost=56574.39..118874.17 rows=117295 width=620) Hash Cond: (t1.number = t2.number) -> Index Scan using mov_con_x10 on mov_con t1 (cost=0.00..52469.07 rows=351884 width=620) -> Hash (cost=55108.20..55108.20 rows=117295 width=11) -> Index Scan using mov_con_x10 on mov_con t2 (cost=0.00..55108.20 rows=117295 width=11) Filter: (abs((amount - total_amo)) > 0.1::double precision) Il 09/01/2012 15.59, Szymon Guz ha scritto: On 9 January 2012 15:41, Silvio Brandani <mailto:silvio.brand...@tech.sdb.it>> wrote: In the last few hours we get a problem with following query in Production database : select * from "001".mov_con where number in ( select number from "001".mov_con where abs(amount-total_amo)>0.1) ; The correct plan should be QUERY PLAN -- -- -- --- Nested Loop (cost=541763.01..584606.03 rows=1249640 width=360) -> HashAggregate (cost=541763.01..541807.55 rows=4454 width=10) -> Index Scan using mov_con_x9 on mov_con t2 (cost=0.00..538639.38 rows=1249452 width=10) Filter: (abs((amount - total_amo)) > 0.1::double precision) -> Index Scan using mov_con_pkey on mov_con t1 (cost=0.00..6.10 rows=281 width=360) Index Cond: (t1.number = t2.number) (6 rows) instead we get the following WRONG one: QUERY PLAN -- -- -- - Nested Loop IN Join (cost=0.00..52906.16 rows=117499 width=620) -> Index Scan using mov_con_x10 on mov_con t1 (cost=0.00..52483.90 rows=352486 width=620) -> Index Scan using mov_con_x10 on mov_con t2 (cost=0.00..0.72 rows=3 width=11) Index Cond: (t2.number = t1.number) Filter: (abs((t2.amount - t2.total_amo)) > 0.1::double precision) So I go to see statistics and try to change the default_statistics_target from 10 to 100 , reload the configuration and vacuum the table and the result is that while the other tables have now 100 values on pg_stats the mov_con table still have the same values SELECT * FROM pg_stats WHERE tablename='mov_con' AND attname='number' ; So there is something wrong with table statistics. How can I reset the pg_statistics for this table??? Any comment higly appreciated. Hi, did you make only vacuum, or vacuum analyze? Simple vacuum does not change stats, analyze does (or vacuum analyze). regards Szymon -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalit� amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilit� giuridica qualora pervengano da questo indirizzo messaggi estranei all'attivit� lavorativa o contrari a norme. --
[ADMIN] problem on table statistics
In the last few hours we get a problem with following query in Production database : select * from "001".mov_con where number in ( select number from "001".mov_con where abs(amount-total_amo)>0.1) ; The correct plan should be QUERY PLAN - Nested Loop (cost=541763.01..584606.03 rows=1249640 width=360) -> HashAggregate (cost=541763.01..541807.55 rows=4454 width=10) -> Index Scan using mov_con_x9 on mov_con t2 (cost=0.00..538639.38 rows=1249452 width=10) Filter: (abs((amount - total_amo)) > 0.1::double precision) -> Index Scan using mov_con_pkey on mov_con t1 (cost=0.00..6.10 rows=281 width=360) Index Cond: (t1.number = t2.number) (6 rows) instead we get the following WRONG one: QUERY PLAN --- Nested Loop IN Join (cost=0.00..52906.16 rows=117499 width=620) -> Index Scan using mov_con_x10 on mov_con t1 (cost=0.00..52483.90 rows=352486 width=620) -> Index Scan using mov_con_x10 on mov_con t2 (cost=0.00..0.72 rows=3 width=11) Index Cond: (t2.number = t1.number) Filter: (abs((t2.amount - t2.total_amo)) > 0.1::double precision) So I go to see statistics and try to change the default_statistics_target from 10 to 100 , reload the configuration and vacuum the table and the result is that while the other tables have now 100 values on pg_stats the mov_con table still have the same values SELECT * FROM pg_stats WHERE tablename='mov_con' AND attname='number' ; So there is something wrong with table statistics. How can I reset the pg_statistics for this table??? Any comment higly appreciated. -- Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] truncate table in pitr system
I have a system with archive log shipping to a standby server read only with replication streaming. is possible to use the truncate in the primary or it will affect the log shipping architecture and will corrupt the standby server?? thanks -- Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] database not using indexes, yet
Il 18/11/2011 15.51, Tom Lane ha scritto: Silvio Brandani writes: On postgres 8.3.11 on linux centos 5 we have a table not too big with primary key index on Indexes: "aida_references_pkey" PRIMARY KEY, btree (aida_reference_id) the query not use index: aidadb=# explain analyze select aida_reference_id from aida.aida_references where aida_reference_id = '3145'; QUERY PLAN Seq Scan on aida_references (cost=0.00..51489.15 rows=1 width=4) (actual time=0.173..1457.643 rows=1 loops=1) Filter: (aida_reference_id = 3145) Total runtime: 1457.696 ms There's nothing here to suggest that this query shouldn't use an index, so the problem is in something you didn't show us. Maybe you have enable_indexscan turned off, or maybe that index isn't really on that table, or something else. regards, tom lane this is not the case, to be sure I have recreated the index and still not work. moreover the copy of the table with the same ttpe of index is using it. I have vacuum full the table and still not work, how can I rebuild this table ? this is a production database.. thanks -- Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] database not using indexes, yet
table is 959818 records, I create a copy of the table with create tabase as select ... and then indexed, the new table use the indexes ... thanks Il 18/11/2011 15.19, Szymon Guz ha scritto: 2011/11/18 Silvio Brandani <mailto:silvio.brand...@tech.sdb.it>> On postgres 8.3.11 on linux centos 5 we have a table not too big with primary key index on Indexes: "aida_references_pkey" PRIMARY KEY, btree (aida_reference_id) the query not use index: aidadb=# explain analyze select aida_reference_id from aida.aida_references where aida_reference_id = '3145'; QUERY PLAN Seq Scan on aida_references (cost=0.00..51489.15 rows=1 width=4) (actual time=0.173..1457.643 rows=1 loops=1) Filter: (aida_reference_id = 3145) Total runtime: 1457.696 ms already executed the vacuum ,reindex. Please help -- Silvio Brandani Hi Silvio, how many rows do you have in the table? Usually PostgreSQL doesn't want to use index when the table is small. regards Szymon -- *http://simononsoftware.com/* -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalit� amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilit� giuridica qualora pervengano da questo indirizzo messaggi estranei all'attivit� lavorativa o contrari a norme. --
[ADMIN] database not using indexes, yet
On postgres 8.3.11 on linux centos 5 we have a table not too big with primary key index on Indexes: "aida_references_pkey" PRIMARY KEY, btree (aida_reference_id) the query not use index: aidadb=# explain analyze select aida_reference_id from aida.aida_references where aida_reference_id = '3145'; QUERY PLAN Seq Scan on aida_references (cost=0.00..51489.15 rows=1 width=4) (actual time=0.173..1457.643 rows=1 loops=1) Filter: (aida_reference_id = 3145) Total runtime: 1457.696 ms already executed the vacuum ,reindex. Please help -- Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] database not using indexes
Ok, the problem was on a big table on query like this: select outmessage0_.out_msg_id as out1_0_ from edi.out_messages outmessage0_, edi.transaction_set_partners transactio1_ where outmessage0_.transaction_set_partner=transactio1_.trn_set_prtn_id and outmessage0_.status_id='TOSND' and transactio1_.legacy_sender_id='ALL' and transactio1_.legacy_receiver_id='4542' and outmessage0_.transaction_set_id='INTERNAL_USE' order by outmessage0_.out_msg_id the existing indexes on status_id CREATE INDEX out_msg_status_idex ON edi.out_messages USING btree (status_id); and transaction_set_partners CREATE INDEX edi_out_messages_trn_set_prtn_id_fk_idx ON edi.out_messages USING btree (transaction_set_partner); where not used anyore. I created the following one: CREATE INDEX out_msg_status_trn_set_prtn_idx ON edi.out_messages USING btree (status_id,transaction_set_partner); and still the explain show a seq scan then I inverted the fields and now it works: CREATE INDEX out_msg_status_trn_set_prtn_idx2 ON edi.out_messages USING btree (transaction_set_partner,status_id); I wonder why not use anymore the existing indexes. regards Il 09/11/2011 16.58, Ruslan A. Bondar ha scritto: Why have you decided it isn't using indexes? If index exists - postgres will use it. To write a script for this I need at least database version. On Wed, 09 Nov 2011 16:22:20 +0100 Silvio Brandani wrote: Our database seems not using index anymore, please help with, is a production database. is there a script to check missing index on foreign key ?? thanks a lot --- --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] database not using indexes
Our database seems not using index anymore, please help with, is a production database. is there a script to check missing index on foreign key ?? thanks a lot --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] server - odbc driver compatibility matrix
Hi, where can I found the compatibility matrix between Postgresql server and odbc drivers ?? we are going to upgrade our production databases to 9.0.2 and we get problems with new odbc drivers 9.0.x . So we need to know if the "old" 8.3 or 8.4 drivers are still working from new postgres server version. any comment higly appreciated. -- Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Out of Memory postgres
Il 14/01/2011 21.34, Kevin Grittner ha scritto: Silvio Brandani wrote: I try to change odbc drivers (version 8.x to 9.x) and postgres version (8.3.x to 9.x , Linux platform ) but the error appear in all versions. MessageContext: 1590689792 total in 211 blocks; 8496 free (19 chunks); 1590681296 used Exact versions might be significant. Also, locale information, particularly character set and encoding, at each layer may be significant. I seem to remember some problems with recursive calls within error handling when there were byte sequences which didn't work in the encoding. There has been work to fix that in the PostgreSQL backend, but I don't know about the ODBC driver, and if you're not using the latest version, you might be missing a critical fix. http://www.postgresql.org/support/versioning -Kevin Current version is 8.3.6 but if give error also with 9.0.1 server version. Regarding the ODBC driver we test all last versions (9.0.2, 8.4.0.2) . The encoding used is UTF8 users work on a Turkish language. -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] Out of Memory postgres
_index_indexrelid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_type_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_rewrite_rel_rulename_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_authid_rolname_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_auth_members_member_role_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_enum_typid_label_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_constraint_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_conversion_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used pg_ts_template_tmplname_index: 1024 total in 1 blocks; 280 free (0 chunks); 744 used pg_ts_config_map_index: 1024 total in 1 blocks; 192 free (0 chunks); 832 used pg_namespace_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_type_typname_nsp_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_operator_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_amop_opr_fam_index: 1024 total in 1 blocks; 240 free (0 chunks); 784 used pg_proc_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720 used pg_opfamily_am_name_nsp_index: 1024 total in 1 blocks; 192 free (0 chunks); 832 used pg_ts_template_oid_index: 1024 total in 1 blocks; 344 free (0 chunks); 680 used MdSmgr: 8192 total in 1 blocks; 6664 free (0 chunks); 1528 used LOCALLOCK hash: 8192 total in 1 blocks; 1856 free (0 chunks); 6336 used Timezones: 48616 total in 2 blocks; 5968 free (0 chunks); 42648 used ErrorContext: 24576 total in 3 blocks; 24528 free (22 chunks); 48 used ERROR: out of memory DETAIL: Failed on request of size 16. ERROR: current transaction is aborted, commands ignored until end of transaction block STATEMENT: close SQL_CUR02B79258 LOG: statement: ROLLBACK -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] data mount point lost permissions
During a server restart the mount point /var/lib/pgsql/data lost the 0700 permission and the automatic restart of postgres failed. How can I set the permission of this mount point to be not lost during restart of server ?? Have I to set specific option in fstab?? thanks --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] reindex script
Kevin Grittner ha scritto: Silvio Brandani wrote: Is it possible to use a reindex in a share lock mode ?? Check out the CONCURRENTLY keyword in CREATE INDEX: http://www.postgresql.org/docs/current/interactive/sql-createindex.html You could create a duplicate index concurrently, drop the old index, and rename the new one to the old name. -Kevin we really need to migrate to version postges 9.x . thanks, --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] reindex script
we are using reindex on single defragmented indexes on a nigtly schedule script. last night we encounter a problem of lock , a idle in transaction connection keep a lock on the table and the reindex was in a wating status and other connections were in a BIND waiting. Is it possible to use a reindex in a share lock mode ?? we have a 8.3 version. In higher postgres version the reindex mode change? thanks a lot Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] PANIC killing vacuum process
Silvio Brandani ha scritto: Kevin Grittner ha scritto: Scott Marlowe wrote: Silvio Brandani wrote: we have develop a script to execute the vacuum full on all tables Vacuum full is more of a recovery / offline command and is to be used sparingly, especially before 9.0. And before 9.0, most of the situations where you might reasonably consider VACUUM FULL, you were better off with CLUSTER. very big database , since it is a 24 x 7 available system we have not a timeframe to exec the vacuum full. Is there a reason you're avoiding autovacuum and tuning it to keep up? It's usually the better option. Even if you have a case for doing database vacuums during off-peak hours, you should almost certainly use autovacuum with settings at least as aggressive as the default. At our shop we configure autovacuum more aggressively than the default, to keep our small, volatile tables tidy, and run a vacuum of the entire database each night (which is, by the way, a very different thing than a VACUUM FULL). PostgreSQL 8.3.1 on x86_64-redhat-linux-gnu Is there a good reason for avoiding about two years of updates (8.3.latest has a lot of bug fixes.) Yeah, this is important. See this page: http://www.postgresql.org/support/versioning Many of those fixes to 8.3 after 8.3.1 were to vacuum or autovacuum. You can poke around the release notes here: http://www.postgresql.org/docs/8.3/static/release.html If problems with autovacuum were what drove you toward VACUUM FULL, you should update and try autovacuum again. Going from 8.3.1 to 8.3.12 is pretty painless and very safe -- just read the release notes for details on what types of indexes need to be rebuilt after the update. (That probably won't affect you, but you should check.) -Kevin Thanks a lot. We will migrate to 8.3.12 and keep autovacuum running instead of vauum full. the postgres 9.0.x could be consider a stable version ?? or is better to wait 9.1 , in this case when will be released ?? thanks -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] PANIC killing vacuum process
Kevin Grittner ha scritto: Scott Marlowe wrote: Silvio Brandani wrote: we have develop a script to execute the vacuum full on all tables Vacuum full is more of a recovery / offline command and is to be used sparingly, especially before 9.0. And before 9.0, most of the situations where you might reasonably consider VACUUM FULL, you were better off with CLUSTER. very big database , since it is a 24 x 7 available system we have not a timeframe to exec the vacuum full. Is there a reason you're avoiding autovacuum and tuning it to keep up? It's usually the better option. Even if you have a case for doing database vacuums during off-peak hours, you should almost certainly use autovacuum with settings at least as aggressive as the default. At our shop we configure autovacuum more aggressively than the default, to keep our small, volatile tables tidy, and run a vacuum of the entire database each night (which is, by the way, a very different thing than a VACUUM FULL). PostgreSQL 8.3.1 on x86_64-redhat-linux-gnu Is there a good reason for avoiding about two years of updates (8.3.latest has a lot of bug fixes.) Yeah, this is important. See this page: http://www.postgresql.org/support/versioning Many of those fixes to 8.3 after 8.3.1 were to vacuum or autovacuum. You can poke around the release notes here: http://www.postgresql.org/docs/8.3/static/release.html If problems with autovacuum were what drove you toward VACUUM FULL, you should update and try autovacuum again. Going from 8.3.1 to 8.3.12 is pretty painless and very safe -- just read the release notes for details on what types of indexes need to be rebuilt after the update. (That probably won't affect you, but you should check.) -Kevin Thanks a lot. We will migrate to 8.3.12 and keep autovacuum running instead of vauum full. -- Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] PANIC killing vacuum process
Tom Lane ha scritto: "Kevin Grittner" writes: Silvio Brandani wrote: we have develop a script to execute the vacuum full on all tables of our very big database , since it is a 24 x 7 available system we have not a timeframe to exec the vacuum full. so we try with this script running the vauum full table by table and if the vacuum generate the waiting status for other connections we kill the vacuum . [ and get ] 2010-11-03 14:25:27 CET [19324]: [6-1] PANIC: cannot abort transaction 75073917, it was already committed What version of PostgreSQL is this? Anything pre-9.0 might do that; it's one of the known problems with the old VACUUM FULL implementation that made us decide to get rid of it. However, versions that are less than about a year old do have a hack that should avoid the PANIC for a query-cancel interrupt ... at the cost of ignoring the cancel interrupt, so that's not all that helpful a solution here. Is it possible to softly kill a vacuum process without risk a panic ? Normally, yes. VACUUM FULL is more prone to problems than a normal vacuum, especially if you are using an old version. There are very few circumstances where VACUUM FULL is the right thing to use. Indeed. If you think you need to use VACUUM FULL on a routine basis, rethink that. regards, tom lane We were running vacuum full because of a lot of IO problems , so we try this way to reorganize tables should be better thane normal vacuum or you think the benefits of running vacuum full are not so good to run it and a normal vacuum analyze is enough ??? thanks, -- Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] PANIC killing vacuum process
Kevin Grittner ha scritto: Silvio Brandani wrote: we have develop a script to execute the vacuum full on all tables of our very big database , since it is a 24 x 7 available system we have not a timeframe to exec the vacuum full. so we try with this script running the vauum full table by table and if the vacuum generate the waiting status for other connections we kill the vacuum . But we encounter following problem: with kill command: 2010-11-03 14:25:27 CET [19324]: [4-1] FATAL: terminating connection due to administrator command 2010-11-03 14:25:27 CET [19324]: [5-1] STATEMENT: vacuum full analyze verbose tracking.as_history_status ; 2010-11-03 14:25:27 CET [19324]: [6-1] PANIC: cannot abort transaction 75073917, it was already committed with pg_cancel_backend(pid) command: CPU 0.18s/0.26u sec elapsed 3.79 sec. ERROR: canceling statement due to user request PANIC: cannot abort transaction 75081452, it was already committed server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. !> quit -> \q the server crash and we have a service unavailiability on our production system. What version of PostgreSQL is this? Is it possible to softly kill a vacuum process without risk a panic ? Normally, yes. VACUUM FULL is more prone to problems than a normal vacuum, especially if you are using an old version. There are very few circumstances where VACUUM FULL is the right thing to use. Have you recovered your database yet? If so how? (Restart, PITR backup, pg_dump output, etc.) -Kevin We had to kill the postmaster and restart the database recovering it. thanks -- Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] PANIC killing vacuum process
Kevin Grittner ha scritto: Silvio Brandani wrote: we have develop a script to execute the vacuum full on all tables of our very big database , since it is a 24 x 7 available system we have not a timeframe to exec the vacuum full. so we try with this script running the vauum full table by table and if the vacuum generate the waiting status for other connections we kill the vacuum . But we encounter following problem: with kill command: 2010-11-03 14:25:27 CET [19324]: [4-1] FATAL: terminating connection due to administrator command 2010-11-03 14:25:27 CET [19324]: [5-1] STATEMENT: vacuum full analyze verbose tracking.as_history_status ; 2010-11-03 14:25:27 CET [19324]: [6-1] PANIC: cannot abort transaction 75073917, it was already committed with pg_cancel_backend(pid) command: CPU 0.18s/0.26u sec elapsed 3.79 sec. ERROR: canceling statement due to user request PANIC: cannot abort transaction 75081452, it was already committed server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. !> quit -> \q the server crash and we have a service unavailiability on our production system. What version of PostgreSQL is this? Is it possible to softly kill a vacuum process without risk a panic ? Normally, yes. VACUUM FULL is more prone to problems than a normal vacuum, especially if you are using an old version. There are very few circumstances where VACUUM FULL is the right thing to use. Have you recovered your database yet? If so how? (Restart, PITR backup, pg_dump output, etc.) -Kevin Postgres version : PostgreSQL 8.3.1 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14) -- Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] PANIC killing vacuum process
Alls, we have develop a script to execute the vacuum full on all tables of our very big database , since it is a 24 x 7 available system we have not a timeframe to exec the vacuum full. so we try with this script running the vauum full table by table and if the vacuum generate the waiting status for other connections we kill the vacuum . But we encounter following problem: with kill command: 2010-11-03 14:25:27 CET [19324]: [4-1] FATAL: terminating connection due to administrator command 2010-11-03 14:25:27 CET [19324]: [5-1] STATEMENT: vacuum full analyze verbose tracking.as_history_status ; 2010-11-03 14:25:27 CET [19324]: [6-1] PANIC: cannot abort transaction 75073917, it was already committed with pg_cancel_backend(pid) command: CPU 0.18s/0.26u sec elapsed 3.79 sec. ERROR: canceling statement due to user request PANIC: cannot abort transaction 75081452, it was already committed server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. !> quit -> \q the server crash and we have a service unavailiability on our production system. Is it possible to softly kill a vacuum process without risk a panic ? thanks a lot Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] replication solution
Simon Riggs ha scritto: On Tue, 2010-08-24 at 15:46 +0200, Silvio Brandani wrote: Hi all, we are looking for a solution to create a replicated database to be used as reporting database with same data of production ( we can accept a lag of some minutes). we already have the Point In Time Recovery but we need a solution where the standby is always open in readonly , but the data is replicated continuosly from primary. The Slony solution could be a possibility but the production database is 80 Gb of data with around 1 transaction each hour. DO you have some suggestion for our implementaiont if exists?? PostgreSQL 9.0 is production ready now and supports Hot Standby, which is exactly what you want. We are testing postgres 9.0.1 hot-standby feautures in a dev environment. Thanks a lot Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalit� amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/privacy/codice_penale_616.html L'Azienda non si assume alcuna responsabilit� giuridica qualora pervengano da questo indirizzo messaggi estranei all'attivit� lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] out of memory error
Tom Lane ha scritto: Silvio Brandani writes: Tom Lane ha scritto: Is it really the *exact* same query both ways, or are you doing something like parameterizing the query in the application? Is it exactly the same, the query text is from the postgres log. I just try it in test environment and we have same situazione : psql it works, from application (odbc) do not. Hm, there's got to be something different between the two cases. Maybe the odbc application is issuing some SET commands that change the chosen plan? regards, tom lane I trace all the sql executed by application in the logfile then executed in psql and it works. -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] out of memory error
Tom Lane ha scritto: Silvio Brandani writes: Tom Lane ha scritto: Is it really the *exact* same query both ways, or are you doing something like parameterizing the query in the application? Is it exactly the same, the query text is from the postgres log. I just try it in test environment and we have same situazione : psql it works, from application (odbc) do not. Hm, there's got to be something different between the two cases. Maybe the odbc application is issuing some SET commands that change the chosen plan? regards, tom lane Is it possible to check the query plan of an odbc application ?? maybe tracing in the logfile or something else , I know the plan of the query I run on psql that works fine but I don't know the plan of the query with out of memory. Thanks a lot --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] out of memory error
Tom Lane ha scritto: Silvio Brandani writes: Still problems of Out of Memory: the query is the following and if I run it from psql is working fine, but from application I get error : Is it really the *exact* same query both ways, or are you doing something like parameterizing the query in the application? regards, tom lane Is it exactly the same, the query text is from the postgres log. I just try it in test environment and we have same situazione : psql it works, from application (odbc) do not. thanks -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] out of memory error
Silvio Brandani ha scritto:
Still problems of Out of Memory:
the query is the following and if I run it from psql is working fine,
but from application I get error :
SELECT MAX(oec.ctnr_nr) ::char(13) as Ctnr_nr,MAX(oec.file_ref)
::char(7) as File_Ref,MAX(oec.move_type) ::char(5)
as Ctnr_type,MAX(oec.ct_feet) ::char(3) as feet,MAX(cons.nombre)
::char(51) as Consignee,MAX(refs.name_sales) ::char(51)
as Salesman,MAX(refs2.name_principal) ::char(51) as
Cargo_principal,MAX(uslist.username) ::char(50)
as User,MAX(fab.nombre) ::char(51) as Shipper,MAX(agent.nombre)
::char(51) as Dest_Agent,MAX(zmar2.nombre) ::char(61)
as Ocean_Area,MAX(aer_l.codigo) ::char(7) as
Port_Code_L,MAX(zmar3.codigo) ::char(7)
as Ocean_Area_L_Code,MAX(zmar.nombre) ::char(61) as
Ocean_Area,MAX(aer_d.codigo) ::char(7)
as Port_Code_D,MAX(zmar4.codigo) ::char(7) as
Ocean_Area_D_Code,MAX(oev.vessel_name) ::char(31)
as Vessel_Name,MAX(oev.vessel_voy) ::char(11) as
Vessel_Voy,MAX(oevi.departure) as Departure,MAX(cia.nombre) ::char(31)
as SS_Line,MAX(cia2.nom_cod) ::char(5) as Scac_Code,MAX(oes.hbl)
::char(16) as HBL,MAX(oes.mbl) ::char(16)
as BL,SUM(oem.volume) as Volume,MAX(oes.con_venta) ::char(4) as
Incoterm ,MAX(oes.booking_nr) as key1, MAX(oem.progr_ctnr)
as key2 FROM oe_sped_t oes LEFT OUTER JOIN ref_sales refs ON oes.hbl
=refs.house AND oes.expediente = refs.reference
and oes.azienda = refs.azienda LEFT OUTER JOIN ref_sales refs2 ON
oes.hbl =refs2.house AND oes.expediente = refs2.reference
and oes.azienda = refs2.azienda,oe_sped_m oem, oe_container oec,m_cli
cons,open_ref oref,m_cli fab,m_cli agent,
m_aeropu aer_l,m_aeropu aer_d,oe_vessel_t oev,m_cianav cia,m_cianav
cia2,m_zonmar zmar,m_zonmar zmar2,m_zonmar zmar3,
m_zonmar zmar4,oe_vessel_imbarco oevi,users uslist WHERE oes.entry_nr
= oem.entry_nr AND oes.booking_nr = oec.booking_nr
AND oem.progr_ctnr = oec.progr_ctnr AND oes.azienda = oem.azienda AND
oes.azienda = oec.azienda
AND oem.azienda = oec.azienda AND oes.azienda IN ('60') AND
oevi.departure Between '8/1/2010'
AND '8/31/2010' AND oes.cod_des = cons.codigo AND oes.expediente =
oref.reference and oes.azienda =oref.azienda
AND oes.cod_fab = fab.codigo AND oes.agen_des = agent.codigo AND
oes.aero_ori = aer_l.codigo
AND oes.aero_des = aer_d.codigo AND oes.vessel_code = oev.vessel_code
AND oes.azienda = oev.azienda
AND aer_d.zon_mar = zmar.codigo AND aer_d.zon_mar = zmar4.codigo AND
aer_l.zon_mar = zmar2.codigo
AND aer_l.zon_mar = zmar3.codigo AND oes.vessel_code = oevi.vessel_code
AND oes.aero_ori = oevi.port_loading and oes.azienda = oevi.azienda
AND oev.carrier = cia.codigo and oev.azienda=cia.azienda AND
oev.carrier= cia2.codigo and oev.azienda = cia2.azienda
AND oref.id_user=lpad(CAST(uslist.userid as char(6)),6,'0') GROUP BY
oes.azienda,oes.booking_nr,oem.progr_ctnr
And the trace in the logfile is:
TopMemoryContext: 178680 total in 14 blocks; 6624 free (14 chunks);
172056 used
TopTransactionContext: 8192 total in 1 blocks; 7504 free (0 chunks);
688 used
Type information cache: 24576 total in 2 blocks; 11888 free (5
chunks); 12688 used
Operator class cache: 8192 total in 1 blocks; 1680 free (0 chunks);
6512 used
Operator lookup cache: 24576 total in 2 blocks; 11888 free (5
chunks); 12688 used
MessageContext: 3091202048 total in 380 blocks; 41368 free (34
chunks); 3091160680 used
JoinRelHashTable: 1040384 total in 7 blocks; 24336 free (12
chunks); 1016048 used
smgr relation table: 24576 total in 2 blocks; 9776 free (4 chunks);
14800 used
TransactionAbortContext: 32768 total in 1 blocks; 32736 free (0
chunks); 32 used
Portal hash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
PortalMemory: 8192 total in 1 blocks; 8160 free (1 chunks); 32 used
Relcache by OID: 24576 total in 2 blocks; 12832 free (3 chunks);
11744 used
CacheMemoryContext: 2549344 total in 23 blocks; 943032 free (1
chunks); 1606312 used
users_username_key: 2048 total in 1 blocks; 752 free (0 chunks);
1296 used
users_pkey: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used
oevi_1: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used
oe_vessel_imbarco_pkey: 2048 total in 1 blocks; 632 free (0
chunks); 1416 used
m_zonmar_pkey: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used
m_cianav_pkey: 2048 total in 1 blocks; 656 free (0 chunks); 1392 used
oev_1: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used
oe_vessel_t_pkey: 2048 total in 1 blocks; 656 free (0 chunks); 1392
used
m_aeropu_pkey: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used
open_ref_reference_iddept_azienda_key: 2048 total in 1 blocks; 632
free (0 chunks); 1416 used
open_ref_pkey: 2048 total in 1 blocks; 632 free (0 chunks); 1416 used
mcli_nome: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used
mcli_acro: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used
: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used
Re: [ADMIN] out of memory error
id_rolname_index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used pg_auth_members_member_role_index: 3072 total in 2 blocks; 1600 free (2 chunks); 1472 used pg_enum_typid_label_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used pg_constraint_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used pg_conversion_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used pg_ts_template_tmplname_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used pg_ts_config_map_index: 3072 total in 2 blocks; 1624 free (3 chunks); 1448 used pg_namespace_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used pg_type_typname_nsp_index: 3072 total in 2 blocks; 1600 free (2 chunks); 1472 used pg_operator_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used pg_amop_opr_fam_index: 3072 total in 2 blocks; 1600 free (2 chunks); 1472 used pg_proc_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used pg_opfamily_am_name_nsp_index: 3072 total in 2 blocks; 1624 free (3 chunks); 1448 used pg_ts_template_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used MdSmgr: 8192 total in 1 blocks; 5760 free (0 chunks); 2432 used LOCALLOCK hash: 24576 total in 2 blocks; 15984 free (5 chunks); 8592 used Timezones: 53584 total in 2 blocks; 3744 free (0 chunks); 49840 used ErrorContext: 24576 total in 3 blocks; 24480 free (18 chunks); 96 used Any suggestion higly appreciated Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] multiple standby configuration
Is it possible to have multiple host destinations in the archive_command parameter of postgresql.conf to be able to mantain 2 standby datbase with write ahead log??? Can we use something like: archive_command = '/usr/bin/scp -Cv "%p" host_standby1:/var/lib/pgsql/archivelog/"%f" && /usr/bin/scp -Cv "%p" host_standby2:/var/lib/pgsql/archivelog/"%f" ' But in this case if the first scp fail, will skip the second scp command ??? Morevoer, is it possible to architect a cascading standby , that means a secondary standby with the archivelog shipped by the first standby primary-> standby1->standby2 Thanks a lot Silvio B. --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] replication solution
Hi all, we are looking for a solution to create a replicated database to be used as reporting database with same data of production ( we can accept a lag of some minutes). we already have the Point In Time Recovery but we need a solution where the standby is always open in readonly , but the data is replicated continuosly from primary. The Slony solution could be a possibility but the production database is 80 Gb of data with around 1 transaction each hour. DO you have some suggestion for our implementaiont if exists?? thanks a lot Silvio --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] out of memory error
Silvio Brandani ha scritto: Bob Lunney ha scritto: Silvio , I had a similar problem when starting the database from an account that didn't have the appropriate ulimits set. Check the ulimit values using ulimit -a. HTH, Bob Lunney --- On Thu, 8/5/10, Silvio Brandani wrote: From: Silvio Brandani Subject: [ADMIN] out of memory error To: pgsql-admin@postgresql.org Date: Thursday, August 5, 2010, 9:01 AM Hi, a query on our production database give following errror: 2010-08-05 10:52:40 CEST [12106]: [278-1] ERROR: out of memory 2010-08-05 10:52:40 CEST [12106]: [279-1] DETAIL: Failed on request of size 48. any suggestion ? -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin I have the following set: ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited max nice(-e) 0 file size (blocks, -f) unlimited pending signals (-i) 71679 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 max rt priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 71679 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Silvio B it seems the execution plan is different for this query when run from the application versus the psql . How can I check the execution plan of a query run by a user?? I can set explain analyze for the query via psql but how can I check with application running the query??? Thanks --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] out of memory error
Bob Lunney ha scritto: Silvio , I had a similar problem when starting the database from an account that didn't have the appropriate ulimits set. Check the ulimit values using ulimit -a. HTH, Bob Lunney --- On Thu, 8/5/10, Silvio Brandani wrote: From: Silvio Brandani Subject: [ADMIN] out of memory error To: pgsql-admin@postgresql.org Date: Thursday, August 5, 2010, 9:01 AM Hi, a query on our production database give following errror: 2010-08-05 10:52:40 CEST [12106]: [278-1] ERROR: out of memory 2010-08-05 10:52:40 CEST [12106]: [279-1] DETAIL: Failed on request of size 48. any suggestion ? -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin I have the following set: ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited max nice(-e) 0 file size (blocks, -f) unlimited pending signals (-i) 71679 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 max rt priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 71679 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Silvio B --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] out of memory error
Tom Lane ha scritto: "Kevin Grittner" writes: Silvio Brandani wrote: a query on our production database give following errror: 2010-08-05 10:52:40 CEST [12106]: [278-1] ERROR: out of memory 2010-08-05 10:52:40 CEST [12106]: [279-1] DETAIL: Failed on request of size 48. What query? On what OS? Is this a 32-bit or 64-bit build of PostgreSQL? How long does it run before failing. What does memory usage look like before and during the run? Also, out-of-memory should result in a memory usage map getting dumped to the postmaster log. That would be useful to see too. regards, tom lane TopMemoryContext: 178680 total in 14 blocks; 7312 free (16 chunks); 171368 used TopTransactionContext: 8192 total in 1 blocks; 7568 free (0 chunks); 624 used Type information cache: 24576 total in 2 blocks; 11888 free (5 chunks); 12688 used Operator class cache: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used Operator lookup cache: 24576 total in 2 blocks; 11888 free (5 chunks); 12688 used MessageContext: 3409969152 total in 417 blocks; 17496 free (10 chunks); 3409951656 used JoinRelHashTable: 2088960 total in 8 blocks; 851696 free (15 chunks); 1237264 used smgr relation table: 24576 total in 2 blocks; 11840 free (4 chunks); 12736 used TransactionAbortContext: 32768 total in 1 blocks; 32736 free (0 chunks); 32 used Portal hash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used PortalMemory: 8192 total in 1 blocks; 8160 free (1 chunks); 32 used Relcache by OID: 24576 total in 2 blocks; 12832 free (3 chunks); 11744 used CacheMemoryContext: 2549344 total in 23 blocks; 1004136 free (0 chunks); 1545208 used oevi_1: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oe_vessel_imbarco_pkey: 2048 total in 1 blocks; 632 free (0 chunks); 1416 used m_zonmar_pkey: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used m_tipmer_pkey: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used m_cianav_pkey: 2048 total in 1 blocks; 656 free (0 chunks); 1392 used oev_1: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oe_vessel_t_pkey: 2048 total in 1 blocks; 656 free (0 chunks); 1392 used mmerca_cod_emb: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used m_merca_pkey: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used m_aeropu_pkey: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used mcli_nome: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used mcli_acro: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used : 2048 total in 1 blocks; 752 free (0 chunks); 1296 used m_cli_pkey: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oec_2: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oec_1: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oe_container_booking_nr_progr_ctnr_azienda_key: 2048 total in 1 blocks; 632 free (0 chunks); 1416 used oe_container_pkey: 2048 total in 1 blocks; 632 free (0 chunks); 1416 used oem_x1: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oe_sped_m_pkey: 2048 total in 1 blocks; 632 free (0 chunks); 1416 used ref_sales_pkey: 2048 total in 1 blocks; 440 free (0 chunks); 1608 used oes_x7: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oes_x6: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oes_x5: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oes_x4: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oes_x3: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oes_x2: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oes_x1: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used oe_sped_t_pkey: 2048 total in 1 blocks; 656 free (0 chunks); 1392 used navig_save_pkey: 2048 total in 1 blocks; 656 free (0 chunks); 1392 used navig_fields_pkey: 2048 total in 1 blocks; 632 free (0 chunks); 1416 used navig_subarea_pkey: 2048 total in 1 blocks; 656 free (0 chunks); 1392 used navig_area_pkey: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used navig_left_table_pkey: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used gnp_cod_tipo_par: 2048 total in 1 blocks; 608 free (0 chunks); 1440 used gen_param_pkey: 2048 total in 1 blocks; 632 free (0 chunks); 1416 used glchart_groups_pk_gr: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used pg_attrdef_oid_index: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used empresa_pkey: 2048 total in 1 blocks; 704 free (0 chunks); 1344 used pg_attrdef_adrelid_adnum_index: 2048 total in 1 blocks; 608 free (0 chunks); 1440 used pg_index_indrelid_index: 2048 total in 1 blocks; 704 free (0 chunks); 1344 used pg_ts_dict_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used pg_aggregate_fnoid_index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used pg_language_name_index: 3072 total in 2 blocks; 1744 free (3 chunks);
Re: [ADMIN] out of memory error
Victor Hugo ha scritto: Hi Silvio, I don't know if this is relevant. But, work_mem and some other parameters inside postgresql.conf are not set. Here is a portion of the file: shared_buffers = 32MB temp_buffers = 8MB max_prepared_transactions = 5 work_mem = 1MB maintenance_work_mem = 16MB max_stack_depth = 2MB []´s Victor Hugo P.Clemente Brazil 2010/8/5 Silvio Brandani : Hi, a query on our production database give following errror: 2010-08-05 10:52:40 CEST [12106]: [278-1] ERROR: out of memory 2010-08-05 10:52:40 CEST [12106]: [279-1] DETAIL: Failed on request of size 48. any suggestion ? -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin I have tried to increase the parameters but still fail. what is strange is that with psql the query works fine and give result immediatly, with application through odbc the query fail --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] out of memory error
Hi, a query on our production database give following errror: 2010-08-05 10:52:40 CEST [12106]: [278-1] ERROR: out of memory 2010-08-05 10:52:40 CEST [12106]: [279-1] DETAIL: Failed on request of size 48. any suggestion ? -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] performance problems on Delete
Kevin Grittner ha scritto: Silvio Brandani wrote: we have a performance issue on deleting data from a table. the delete is on the index key so should be very fast but the table have 13 contraints of type foreign keys and the slowness seems due to all the works done with the constraint. Trying to drop the constraint and execute the delete the result is immediate. The usual reason for this is that you don't have indexes on the referencing columns, so to check whether the delete is OK it has to scan the related tables. Think about what rows need to be checked to determine whether the delete is allowed and index the columns which will allow fast access to them. -Kevin yes, you where right , an index was missing. thanks a lot -- --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] performance problems on Delete
Hi alls, we have a performance issue on deleting data from a table. the delete is on the index key so should be very fast but the table have 13 contraints of type foreign keys and the slowness seems due to all the works done with the constraint. Trying to drop the constraint and execute the delete the result is immediate. Is there a way to speed up this type of operations?? Any suggestion higly appreciated Silvio --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] postgres data permission
David Bear ha scritto: this doesn't make sense. why go through the overhead of smb to get to a database cluster over a network connection when pg can already work over tcpip sockets and work much more switfly on a local file system? 2010/7/15 Silvio Brandani <mailto:silvio.brand...@tech.sdb.it>> Hi all, I need to start a postgres istance on a samba filesystems /data which have rwxrwxrwx (777) permissions, Ic ould not change such permissions. If I try to start postgres it complain that should be 700 permission . How can I skip this control by postgres startup process and be able to startup istance on this "special folder"?? --- -- David Bear College of Public Programs at ASU 602-494-0424 It is just a special occasion to restore a very big production database in the only place we find enough space... Thanks --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalit� amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilit� giuridica qualora pervengano da questo indirizzo messaggi estranei all'attivit� lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] postgres data permission
Hi all, I need to start a postgres istance on a samba filesystems /data which have rwxrwxrwx (777) permissions, Ic ould not change such permissions. If I try to start postgres it complain that should be 700 permission . How can I skip this control by postgres startup process and be able to startup istance on this "special folder"?? --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] upgrade postgres 8.1.21 to version 8.3.6
Gabriele Bartolini ha scritto: Ciao Silvio, On Tue, 13 Jul 2010 22:52:51 +0200, Iñigo Martinez Lasala You should script database migration process in order to make it faster. Upgrading binaries is really simple. A yum upgrade should be enough. Yes, faster and repeatable. Something you can launch with a script that does everything from scratch. As Iñigo was pointing out, you must pay a lot of attention in setting up a test environment which helps you: * simulate the migration process (and gives you accurate measures of times) * test the applications As Iñigo said, on a typical usage pattern, the most likely set of errors you will encounter are data type checks which require casting. Therefore it becomes crucial to: * setup the test database (preferably on a different server) * setup test applications that interface with the new Postgres database I assume you are using 8.3 because of RPM availability, isn't it? Otherwise, you should think of 8.4. Ciao, Gabriele I have simulate the upgrade process in a test environment - The casting problem in effect occurs, we will provide the required modification at application code before proceeding with the upgrade. thanks a lot - Regards, -- --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalit� amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilit� giuridica qualora pervengano da questo indirizzo messaggi estranei all'attivit� lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] upgrade postgres 8.1.21 to version 8.3.6
We need to upgrade the postgres running on our production system under Red Hat Enterprise Linux Server release 5.1 from version 8.1.21 to version 8.3.6. we could have a stop/maintenance window of 3/4 our the sum of size of databases is around 1G . Which is the best practice to execute such upgrade with possible rollback operation to gain in 3/4 hour this job ?? Any suggestion higly appreciated SB --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] pg_dump: Error message from server: ERROR: missing chunk number
Kevin Grittner ha scritto: Silvio Brandani wrote: We have a standby database During pg_dump Hmm... I just noticed that word "standby" in there. Can you elaborate on what you mean by that? -Kevin It means it is an istance refreshed (via rsync) from another istance which is in recovery mode with log shipping and PITR. So to summarize we have : - a production istance - a pitr istance ( log shipping from production) - a quality istance (the one with error in the backup) which is refreshed with rsync from the pitr istance. - a dev istance that we would like to refresh from the quality with pg_dump / pg_restore -- Silvio Brandani -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] pg_dump: Error message from server: ERROR: missing chunk number
Kevin Grittner ha scritto: Silvio Brandani wrote: We have a standby database During pg_dump Hmm... I just noticed that word "standby" in there. Can you elaborate on what you mean by that? -Kevin It means it is an istance refreshed (via rsync) from another istance which is in recovery mode with log shipping and PITR. So to summarize we have : - a production istance - a pitr istance ( log shipping from production) - a quality istance (the one with error in the backup) which is refreshed with rsync from the pitr istance. - a dev istance that we would like to refresh from the quality with pg_dump / pg_restore -- Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] pg_dump: Error message from server: ERROR: missing chunk number
We have a standby database version postgres 8.3.1 on linux . During pg_dump we get the error: -- pg_dump: SQL command failed -- pg_dump: Error message from server: ERROR: missing chunk number 0 for toast value 254723406 -- pg_dump: The command was: COPY helpdesk.attachments_data (id, filedata, attachment_id) TO stdout; I have already try to reindex and vacuum full the table. but problem still stand. How can we fix this error and get a good dump??-- Any help higly appreciated. --Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] Connection reset by peer
Kevin Grittner ha scritto: Silvio Brandani wrote: postgresql-2010-05-12_053937.log:2010-05-12 06:30:57 CEST [26617]: [288-1] LOG: could not receive data from client: Connection reset by peer postgresql-2010-05-12_053937.log:2010-05-12 06:30:57 CEST [26617]: [289-1] LOG: unexpected EOF on client connection How is it possible to eliminate this disconnection problems? Fix any network problems and convince the clients to terminate their connections gracefully. The server is just reporting that the connection to the client was lost without the client doing the proper handshaking. -Kevin Thanks, could be possible some problem of high resource usage ( low of virtual memory) on client machine (win 2003 server R2) ?? Silvio --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
[ADMIN] Connection reset by peer
We have many postgres installation 8.3.x on different linux servers we get each days a lot of messages like the following: postgresql-2010-05-12_053937.log:2010-05-12 06:30:57 CEST [26617]: [288-1] LOG: could not receive data from client: Connection reset by peer postgresql-2010-05-12_053937.log:2010-05-12 06:30:57 CEST [26617]: [289-1] LOG: unexpected EOF on client connection How is it possible to eliminate this disconnection problems? are they related to postgres configuration or something related to linux or other stuff ? Any suggestion higly appreciated Silvio Brandani --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] postgres invoked oom-killer
Giles Lean ha scritto: Silvio Brandani wrote: yes the server is dedicated to PostgreSQL. Could be a bug of PostgreSQL the fact that the system went Out of Memory?? Wath can be the cause of it? Regards, Silvio The out of memory killer is a totally bogus misfeature of Linux. At least these days they let you turn it off, and everyone should turn it off _and_ should bug their OS vendor to request that they ship their distribution with memory overcommit and the out of memory killer disabled. The "out of memory" killer only exists because Linux by default will allow more memory to be allocated than exists in the system. This is called "memory overcommit" and is kown in operating system circles (outside of Linux) to be a bad thing. The rationale for memory overcommit being a bad thing is that if your OS doesn't allow allocation of more memory than there is in the system, then applications are forced to deal with memory requests that fail, instead of seeing those requests "succeed" and being killed some random time later. Allowing more memory to be "allocated" than exists in the machine is only useful in two circumstances that I know of, and neither apply to a dedicated PostgreSQL system, running Linux or not: 1. When badly written applications allocate far more memory than they use. PostgreSQL isn't like that. The technically correct solution is to fix the applications; allowing memory overcommit is a dangerous workaround that _will_ cause problems. 2. When very large processes need to fork (e.g. a scientific numerical analysis program using most of physical memory) might want to fork to send an email notification or something similar). The technically correct solution is to use vfork(). I won't make myself popular with the Linux zealots, but memory overcommit should just be removed from Linux. It does way more harm than good on any operating system I've ever seen it used on, and the problems it has caused just on Linux are legion. The only OS that had _any_ excuse for memory overcommit I've seen was one that lacked a vfork() system call; they added that call and the justification for memory overcommit went away. Regards, Giles Thanks a lot, I' m going to disable the memory killer, moreover I have run the Operative System watcher scripts to monitor the undergoing activity in case it happens again. Best Regards, Silvio Brandani -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] postgres invoked oom-killer
Silvio Brandani ha scritto: Greg Spiegelberg ha scritto: On Fri, May 7, 2010 at 8:26 AM, Silvio Brandani mailto:silvio.brand...@tech.sdb.it>> wrote: We have a postgres 8.3.8 on linux We get following messages int /var/log/messages: May 6 22:31:01 pgblade02 kernel: postgres invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0 *** snip *** May 6 22:31:30 pgblade02 kernel: Out of memory: Killed process 29076 (postgres). Silvio, Is this system a virtual machine? Greg No is not, is up and runnig from 4 months , 60 G of data in 9 different databases. Lately we import a new schema in one of those databases . Silvio No is not, is up and runnig from 4 months , 60 G of data in 9 different databases. Lately we import a new schema in one of those databases . Silvio --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] postgres invoked oom-killer
Silvio Brandani ha scritto: Lacey Powers ha scritto: Silvio Brandani wrote: We have a postgres 8.3.8 on linux We get following messages int /var/log/messages: May 6 22:31:01 pgblade02 kernel: postgres invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0 May 6 22:31:01 pgblade02 kernel: May 6 22:31:01 pgblade02 kernel: Call Trace: May 6 22:31:19 pgblade02 kernel: [] out_of_memory+0x8e/0x2f5 May 6 22:31:19 pgblade02 kernel: [] __alloc_pages+0x22b/0x2b4 May 6 22:31:19 pgblade02 kernel: [] __do_page_cache_readahead+0x95/0x1d9 May 6 22:31:19 pgblade02 kernel: [] __wait_on_bit_lock+0x5b/0x66 May 6 22:31:19 pgblade02 kernel: [] :dm_mod:dm_any_congested+0x38/0x3f May 6 22:31:19 pgblade02 kernel: [] filemap_nopage+0x148/0x322 May 6 22:31:19 pgblade02 kernel: [] __handle_mm_fault+0x1f8/0xdf4 May 6 22:31:19 pgblade02 kernel: [] do_page_fault+0x4b8/0x81d May 6 22:31:19 pgblade02 kernel: [] thread_return+0x0/0xeb May 6 22:31:19 pgblade02 kernel: [] error_exit+0x0/0x84 May 6 22:31:27 pgblade02 kernel: May 6 22:31:28 pgblade02 kernel: Mem-info: May 6 22:31:28 pgblade02 kernel: Node 0 DMA per-cpu: May 6 22:31:28 pgblade02 kernel: cpu 0 hot: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 0 cold: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 1 hot: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 1 cold: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 2 hot: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 2 cold: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 3 hot: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 3 cold: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: Node 0 DMA32 per-cpu: May 6 22:31:28 pgblade02 kernel: cpu 0 hot: high 186, batch 31 used:27 May 6 22:31:29 pgblade02 kernel: cpu 0 cold: high 62, batch 15 used:54 May 6 22:31:29 pgblade02 kernel: cpu 1 hot: high 186, batch 31 used:23 May 6 22:31:29 pgblade02 kernel: cpu 1 cold: high 62, batch 15 used:49 May 6 22:31:29 pgblade02 kernel: cpu 2 hot: high 186, batch 31 used:12 May 6 22:31:29 pgblade02 kernel: cpu 2 cold: high 62, batch 15 used:14 May 6 22:31:29 pgblade02 kernel: cpu 3 hot: high 186, batch 31 used:50 May 6 22:31:29 pgblade02 kernel: cpu 3 cold: high 62, batch 15 used:60 May 6 22:31:29 pgblade02 kernel: Node 0 Normal per-cpu: May 6 22:31:29 pgblade02 kernel: cpu 0 hot: high 186, batch 31 used:5 May 6 22:31:29 pgblade02 kernel: cpu 0 cold: high 62, batch 15 used:48 May 6 22:31:29 pgblade02 kernel: cpu 1 hot: high 186, batch 31 used:11 May 6 22:31:29 pgblade02 kernel: cpu 1 cold: high 62, batch 15 used:39 May 6 22:31:29 pgblade02 kernel: cpu 2 hot: high 186, batch 31 used:14 May 6 22:31:29 pgblade02 kernel: cpu 2 cold: high 62, batch 15 used:57 May 6 22:31:29 pgblade02 kernel: cpu 3 hot: high 186, batch 31 used:94 May 6 22:31:29 pgblade02 kernel: cpu 3 cold: high 62, batch 15 used:36 May 6 22:31:29 pgblade02 kernel: Node 0 HighMem per-cpu: empty May 6 22:31:29 pgblade02 kernel: Free pages: 41788kB (0kB HighMem) May 6 22:31:29 pgblade02 kernel: Active:974250 inactive:920579 dirty:0 writeback:0 unstable:0 free:10447 slab:11470 mapped-file:985 mapped-anon:1848625 pagetables:111027 May 6 22:31:29 pgblade02 kernel: Node 0 DMA free:11172kB min:12kB low:12kB high:16kB active:0kB inactive:0kB present:10816kB pages_scanned:0 all_unreclaimable? yes May 6 22:31:29 pgblade02 kernel: lowmem_reserve[]: 0 3254 8052 8052 May 6 22:31:29 pgblade02 kernel: Node 0 DMA32 free:23804kB min:4636kB low:5792kB high:6952kB active:1555260kB inactive:1566144kB present:3332668kB pages_scanned:35703257 all_unreclaimable? yes May 6 22:31:29 pgblade02 kernel: lowmem_reserve[]: 0 0 4797 4797 May 6 22:31:29 pgblade02 kernel: Node 0 Normal free:6812kB min:6836kB low:8544kB high:10252kB active:2342332kB inactive:2115836kB present:4912640kB pages_scanned:10165709 all_unreclaimable? yes May 6 22:31:29 pgblade02 kernel: lowmem_reserve[]: 0 0 0 0 May 6 22:31:29 pgblade02 kernel: Node 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no May 6 22:31:29 pgblade02 kernel: lowmem_reserve[]: 0 0 0 0 May 6 22:31:29 pgblade02 kernel: Node 0 DMA: 3*4kB 5*8kB 3*16kB 6*32kB 4*64kB 3*128kB 0*256kB 0*512kB 2*1024kB 0*2048kB 2*4096kB = 11172kB May 6 22:31:29 pgblade02 kernel: Node 0 DMA32: 27*4kB 0*8kB 1*16kB 0*32kB 2*64kB 4*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 5*4096kB = 23804kB May 6 22:31:29 pgblade02 ker if it asks for more memory than is actually available. nel: Node 0 Normal: 21*4kB 9*8kB 26*16kB 3*32kB 6*64kB 5*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 1*4096kB = 6812kB May 6 22:31:29 pgblade02 kernel: Node 0 HighMem: empty May 6 22:31:29 pgblade02 kernel: Swap cache: add 71286821, delete 71287152, find 207780333/216904318, race 1387+10506 May 6 22:31:29 pgblade02 kernel: Free swap = 0kB May 6 22:31:30
Re: [ADMIN] postgres invoked oom-killer
Greg Spiegelberg ha scritto: On Fri, May 7, 2010 at 8:26 AM, Silvio Brandani mailto:silvio.brand...@tech.sdb.it>> wrote: We have a postgres 8.3.8 on linux We get following messages int /var/log/messages: May 6 22:31:01 pgblade02 kernel: postgres invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0 *** snip *** May 6 22:31:30 pgblade02 kernel: Out of memory: Killed process 29076 (postgres). Silvio, Is this system a virtual machine? Greg No is not, is up and runnig from 4 months , 60 G of data in 9 different databases. Lately we import a new schema in one of those databases . Silvio -- Silvio Brandani Infrastructure Administrator SDB Information Technology Phone: +39.055.3811222 Fax: +39.055.5201119 --- Utilizziamo i dati personali che la riguardano esclusivamente per nostre finalità amministrative e contabili, anche quando li comunichiamo a terzi. Informazioni dettagliate, anche in ordine al Suo diritto di accesso e agli altri Suoi diritti, sono riportate alla pagina http://www.savinodelbene.com/news/privacy.html Se avete ricevuto questo messaggio per errore Vi preghiamo di ritornarlo al mittente eliminandolo assieme agli eventuali allegati, ai sensi art. 616 codice penale http://www.savinodelbene.com/codice_penale_616.html L'Azienda non si assume alcuna responsabilità giuridica qualora pervengano da questo indirizzo messaggi estranei all'attività lavorativa o contrari a norme. -- -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
Re: [ADMIN] postgres invoked oom-killer
Lacey Powers ha scritto: Silvio Brandani wrote: We have a postgres 8.3.8 on linux We get following messages int /var/log/messages: May 6 22:31:01 pgblade02 kernel: postgres invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0 May 6 22:31:01 pgblade02 kernel: May 6 22:31:01 pgblade02 kernel: Call Trace: May 6 22:31:19 pgblade02 kernel: [] out_of_memory+0x8e/0x2f5 May 6 22:31:19 pgblade02 kernel: [] __alloc_pages+0x22b/0x2b4 May 6 22:31:19 pgblade02 kernel: [] __do_page_cache_readahead+0x95/0x1d9 May 6 22:31:19 pgblade02 kernel: [] __wait_on_bit_lock+0x5b/0x66 May 6 22:31:19 pgblade02 kernel: [] :dm_mod:dm_any_congested+0x38/0x3f May 6 22:31:19 pgblade02 kernel: [] filemap_nopage+0x148/0x322 May 6 22:31:19 pgblade02 kernel: [] __handle_mm_fault+0x1f8/0xdf4 May 6 22:31:19 pgblade02 kernel: [] do_page_fault+0x4b8/0x81d May 6 22:31:19 pgblade02 kernel: [] thread_return+0x0/0xeb May 6 22:31:19 pgblade02 kernel: [] error_exit+0x0/0x84 May 6 22:31:27 pgblade02 kernel: May 6 22:31:28 pgblade02 kernel: Mem-info: May 6 22:31:28 pgblade02 kernel: Node 0 DMA per-cpu: May 6 22:31:28 pgblade02 kernel: cpu 0 hot: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 0 cold: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 1 hot: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 1 cold: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 2 hot: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 2 cold: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 3 hot: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 3 cold: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: Node 0 DMA32 per-cpu: May 6 22:31:28 pgblade02 kernel: cpu 0 hot: high 186, batch 31 used:27 May 6 22:31:29 pgblade02 kernel: cpu 0 cold: high 62, batch 15 used:54 May 6 22:31:29 pgblade02 kernel: cpu 1 hot: high 186, batch 31 used:23 May 6 22:31:29 pgblade02 kernel: cpu 1 cold: high 62, batch 15 used:49 May 6 22:31:29 pgblade02 kernel: cpu 2 hot: high 186, batch 31 used:12 May 6 22:31:29 pgblade02 kernel: cpu 2 cold: high 62, batch 15 used:14 May 6 22:31:29 pgblade02 kernel: cpu 3 hot: high 186, batch 31 used:50 May 6 22:31:29 pgblade02 kernel: cpu 3 cold: high 62, batch 15 used:60 May 6 22:31:29 pgblade02 kernel: Node 0 Normal per-cpu: May 6 22:31:29 pgblade02 kernel: cpu 0 hot: high 186, batch 31 used:5 May 6 22:31:29 pgblade02 kernel: cpu 0 cold: high 62, batch 15 used:48 May 6 22:31:29 pgblade02 kernel: cpu 1 hot: high 186, batch 31 used:11 May 6 22:31:29 pgblade02 kernel: cpu 1 cold: high 62, batch 15 used:39 May 6 22:31:29 pgblade02 kernel: cpu 2 hot: high 186, batch 31 used:14 May 6 22:31:29 pgblade02 kernel: cpu 2 cold: high 62, batch 15 used:57 May 6 22:31:29 pgblade02 kernel: cpu 3 hot: high 186, batch 31 used:94 May 6 22:31:29 pgblade02 kernel: cpu 3 cold: high 62, batch 15 used:36 May 6 22:31:29 pgblade02 kernel: Node 0 HighMem per-cpu: empty May 6 22:31:29 pgblade02 kernel: Free pages: 41788kB (0kB HighMem) May 6 22:31:29 pgblade02 kernel: Active:974250 inactive:920579 dirty:0 writeback:0 unstable:0 free:10447 slab:11470 mapped-file:985 mapped-anon:1848625 pagetables:111027 May 6 22:31:29 pgblade02 kernel: Node 0 DMA free:11172kB min:12kB low:12kB high:16kB active:0kB inactive:0kB present:10816kB pages_scanned:0 all_unreclaimable? yes May 6 22:31:29 pgblade02 kernel: lowmem_reserve[]: 0 3254 8052 8052 May 6 22:31:29 pgblade02 kernel: Node 0 DMA32 free:23804kB min:4636kB low:5792kB high:6952kB active:1555260kB inactive:1566144kB present:3332668kB pages_scanned:35703257 all_unreclaimable? yes May 6 22:31:29 pgblade02 kernel: lowmem_reserve[]: 0 0 4797 4797 May 6 22:31:29 pgblade02 kernel: Node 0 Normal free:6812kB min:6836kB low:8544kB high:10252kB active:2342332kB inactive:2115836kB present:4912640kB pages_scanned:10165709 all_unreclaimable? yes May 6 22:31:29 pgblade02 kernel: lowmem_reserve[]: 0 0 0 0 May 6 22:31:29 pgblade02 kernel: Node 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no May 6 22:31:29 pgblade02 kernel: lowmem_reserve[]: 0 0 0 0 May 6 22:31:29 pgblade02 kernel: Node 0 DMA: 3*4kB 5*8kB 3*16kB 6*32kB 4*64kB 3*128kB 0*256kB 0*512kB 2*1024kB 0*2048kB 2*4096kB = 11172kB May 6 22:31:29 pgblade02 kernel: Node 0 DMA32: 27*4kB 0*8kB 1*16kB 0*32kB 2*64kB 4*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 5*4096kB = 23804kB May 6 22:31:29 pgblade02 ker if it asks for more memory than is actually available. nel: Node 0 Normal: 21*4kB 9*8kB 26*16kB 3*32kB 6*64kB 5*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 1*4096kB = 6812kB May 6 22:31:29 pgblade02 kernel: Node 0 HighMem: empty May 6 22:31:29 pgblade02 kernel: Swap cache: add 71286821, delete 71287152, find 207780333/216904318, race 1387+10506 May 6 22:31:29 pgblade02 kernel: Free swap = 0kB May 6 22:31:30 pgblade02 kernel: Total swap
[ADMIN] postgres invoked oom-killer
We have a postgres 8.3.8 on linux We get following messages int /var/log/messages: May 6 22:31:01 pgblade02 kernel: postgres invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0 May 6 22:31:01 pgblade02 kernel: May 6 22:31:01 pgblade02 kernel: Call Trace: May 6 22:31:19 pgblade02 kernel: [] out_of_memory+0x8e/0x2f5 May 6 22:31:19 pgblade02 kernel: [] __alloc_pages+0x22b/0x2b4 May 6 22:31:19 pgblade02 kernel: [] __do_page_cache_readahead+0x95/0x1d9 May 6 22:31:19 pgblade02 kernel: [] __wait_on_bit_lock+0x5b/0x66 May 6 22:31:19 pgblade02 kernel: [] :dm_mod:dm_any_congested+0x38/0x3f May 6 22:31:19 pgblade02 kernel: [] filemap_nopage+0x148/0x322 May 6 22:31:19 pgblade02 kernel: [] __handle_mm_fault+0x1f8/0xdf4 May 6 22:31:19 pgblade02 kernel: [] do_page_fault+0x4b8/0x81d May 6 22:31:19 pgblade02 kernel: [] thread_return+0x0/0xeb May 6 22:31:19 pgblade02 kernel: [] error_exit+0x0/0x84 May 6 22:31:27 pgblade02 kernel: May 6 22:31:28 pgblade02 kernel: Mem-info: May 6 22:31:28 pgblade02 kernel: Node 0 DMA per-cpu: May 6 22:31:28 pgblade02 kernel: cpu 0 hot: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 0 cold: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 1 hot: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 1 cold: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 2 hot: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 2 cold: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 3 hot: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: cpu 3 cold: high 0, batch 1 used:0 May 6 22:31:28 pgblade02 kernel: Node 0 DMA32 per-cpu: May 6 22:31:28 pgblade02 kernel: cpu 0 hot: high 186, batch 31 used:27 May 6 22:31:29 pgblade02 kernel: cpu 0 cold: high 62, batch 15 used:54 May 6 22:31:29 pgblade02 kernel: cpu 1 hot: high 186, batch 31 used:23 May 6 22:31:29 pgblade02 kernel: cpu 1 cold: high 62, batch 15 used:49 May 6 22:31:29 pgblade02 kernel: cpu 2 hot: high 186, batch 31 used:12 May 6 22:31:29 pgblade02 kernel: cpu 2 cold: high 62, batch 15 used:14 May 6 22:31:29 pgblade02 kernel: cpu 3 hot: high 186, batch 31 used:50 May 6 22:31:29 pgblade02 kernel: cpu 3 cold: high 62, batch 15 used:60 May 6 22:31:29 pgblade02 kernel: Node 0 Normal per-cpu: May 6 22:31:29 pgblade02 kernel: cpu 0 hot: high 186, batch 31 used:5 May 6 22:31:29 pgblade02 kernel: cpu 0 cold: high 62, batch 15 used:48 May 6 22:31:29 pgblade02 kernel: cpu 1 hot: high 186, batch 31 used:11 May 6 22:31:29 pgblade02 kernel: cpu 1 cold: high 62, batch 15 used:39 May 6 22:31:29 pgblade02 kernel: cpu 2 hot: high 186, batch 31 used:14 May 6 22:31:29 pgblade02 kernel: cpu 2 cold: high 62, batch 15 used:57 May 6 22:31:29 pgblade02 kernel: cpu 3 hot: high 186, batch 31 used:94 May 6 22:31:29 pgblade02 kernel: cpu 3 cold: high 62, batch 15 used:36 May 6 22:31:29 pgblade02 kernel: Node 0 HighMem per-cpu: empty May 6 22:31:29 pgblade02 kernel: Free pages: 41788kB (0kB HighMem) May 6 22:31:29 pgblade02 kernel: Active:974250 inactive:920579 dirty:0 writeback:0 unstable:0 free:10447 slab:11470 mapped-file:985 mapped-anon:1848625 pagetables:111027 May 6 22:31:29 pgblade02 kernel: Node 0 DMA free:11172kB min:12kB low:12kB high:16kB active:0kB inactive:0kB present:10816kB pages_scanned:0 all_unreclaimable? yes May 6 22:31:29 pgblade02 kernel: lowmem_reserve[]: 0 3254 8052 8052 May 6 22:31:29 pgblade02 kernel: Node 0 DMA32 free:23804kB min:4636kB low:5792kB high:6952kB active:1555260kB inactive:1566144kB present:3332668kB pages_scanned:35703257 all_unreclaimable? yes May 6 22:31:29 pgblade02 kernel: lowmem_reserve[]: 0 0 4797 4797 May 6 22:31:29 pgblade02 kernel: Node 0 Normal free:6812kB min:6836kB low:8544kB high:10252kB active:2342332kB inactive:2115836kB present:4912640kB pages_scanned:10165709 all_unreclaimable? yes May 6 22:31:29 pgblade02 kernel: lowmem_reserve[]: 0 0 0 0 May 6 22:31:29 pgblade02 kernel: Node 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no May 6 22:31:29 pgblade02 kernel: lowmem_reserve[]: 0 0 0 0 May 6 22:31:29 pgblade02 kernel: Node 0 DMA: 3*4kB 5*8kB 3*16kB 6*32kB 4*64kB 3*128kB 0*256kB 0*512kB 2*1024kB 0*2048kB 2*4096kB = 11172kB May 6 22:31:29 pgblade02 kernel: Node 0 DMA32: 27*4kB 0*8kB 1*16kB 0*32kB 2*64kB 4*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 5*4096kB = 23804kB May 6 22:31:29 pgblade02 kernel: Node 0 Normal: 21*4kB 9*8kB 26*16kB 3*32kB 6*64kB 5*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 1*4096kB = 6812kB May 6 22:31:29 pgblade02 kernel: Node 0 HighMem: empty May 6 22:31:29 pgblade02 kernel: Swap cache: add 71286821, delete 71287152, find 207780333/216904318, race 1387+10506 May 6 22:31:29 pgblade02 kernel: Free swap = 0kB May 6 22:31:30 pgblade02 kernel: Total swap = 8388600kB May 6 22:31:30 pgblade02 kernel: Free swap:0kB May 6 22:31:30 pgblade02 kernel: 2293759 pag
