pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedout of memory error
42+ messages / 17 participants
[nested] [flat]
* out of memory error
@ 2004-06-08 00:01 Adi Alurkar <adi@sf.net>
0 siblings, 0 replies; 42+ messages in thread
From: Adi Alurkar @ 2004-06-08 00:01 UTC (permalink / raw)
To: pgsql-admin; pgsql-bugs@postgresql.org
Greetings,
During testing of our application we ran into a very odd error:
very randomly during the test the postgresql log file showed a "ERROR:
53200: out of memory"
we changed the logging configuration to log statements causing errors
and found the error to be caused by a SELECT,
here is the relevant info from postgresql log file :
ERROR: 53200: out of memory
DETAIL: Failed on request of size 188
LOCATION: AllocSetAlloc, aset.c:700
Interestingly the box did not OOM (i.e nothing in /var/log/messages)
running RHAS3 with PG 7.4.2
-bash-2.05b$ id
uid=26(postgres) gid=26(postgres) groups=26(postgres)
-bash-2.05b$ psql -V
psql (PostgreSQL) 7.4.2
contains support for command-line editing
-bash-2.05b$ cat /etc/redhat-release
Red Hat Enterprise Linux ES release 3 (Taroon)
-bash-2.05b$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited
This happens randomly, when the failing SELECT was run via psql it
executed w/o error.
Any suggestions on how this can be debugged?
-Adi
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2004-06-08 00:36 Jie Liang <jie@stbernard.com>
0 siblings, 0 replies; 42+ messages in thread
From: Jie Liang @ 2004-06-08 00:36 UTC (permalink / raw)
To: Adi Alurkar <adi@sf.net>; pgsql-admin; pgsql-bugs@postgresql.org
I had a similar problem after upgrade to 7.4.2,
Try:
SET enable_hashagg = false;
Before you execute that SELECT stmt
If you don't want disable it in postgresql.conf
Jie Liang
-----Original Message-----
From: Adi Alurkar [mailto:adi@sf.net]
Sent: Monday, June 07, 2004 5:01 PM
To: pgsql-admin@postgresql.org; pgsql-bugs@postgresql.org
Subject: [ADMIN] out of memory error
Greetings,
During testing of our application we ran into a very odd error:
very randomly during the test the postgresql log file showed a "ERROR:
53200: out of memory"
we changed the logging configuration to log statements causing errors
and found the error to be caused by a SELECT,
here is the relevant info from postgresql log file :
ERROR: 53200: out of memory
DETAIL: Failed on request of size 188
LOCATION: AllocSetAlloc, aset.c:700
Interestingly the box did not OOM (i.e nothing in /var/log/messages)
running RHAS3 with PG 7.4.2
-bash-2.05b$ id
uid=26(postgres) gid=26(postgres) groups=26(postgres) -bash-2.05b$ psql
-V psql (PostgreSQL) 7.4.2 contains support for command-line editing
-bash-2.05b$ cat /etc/redhat-release Red Hat Enterprise Linux ES release
3 (Taroon) -bash-2.05b$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited
This happens randomly, when the failing SELECT was run via psql it
executed w/o error.
Any suggestions on how this can be debugged?
-Adi
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2004-06-08 17:28 Naomi Walker <nwalke@eldocomp.com>
0 siblings, 0 replies; 42+ messages in thread
From: Naomi Walker @ 2004-06-08 17:28 UTC (permalink / raw)
To: Jie Liang <jie@stbernard.com>; +Cc: Adi Alurkar <adi@sf.net>; pgsql-admin; pgsql-bugs@postgresql.org <pgsql-bugs@postgresql.org>
Jie Liang wrote:
Does 7.3* support this? Can you tell me a bit more about it, please?
Hash aggregate..?
>I had a similar problem after upgrade to 7.4.2,
>Try:
>SET enable_hashagg = false;
>Before you execute that SELECT stmt
>If you don't want disable it in postgresql.conf
>
>Jie Liang
>
>
>
--------------------------------
-- CONFIDENTIALITY NOTICE --
This message is intended for the sole use of the individual and entity to whom it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended addressee, nor authorized to receive for the intended addressee, you are hereby notified that you may not use, copy, disclose or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email, and delete the message. Thank you.
^ permalink raw reply [nested|flat] 42+ messages in thread
* out of memory error
@ 2004-06-11 01:14 Mark Striebeck <mstriebeck@vasoftware.com>
0 siblings, 2 replies; 42+ messages in thread
From: Mark Striebeck @ 2004-06-11 01:14 UTC (permalink / raw)
To: pgsql-admin; pgsql-general@postgresql.org
Hi,
we are using Postgres with a J2EE application (JBoss) and get
intermittent "out of memory" errors on the Postgres database. We are
running on a fairly large Linux server (Dual 3GHz, 2GB Ram) with the
following parameters:
shared_buffers = 8192
sort_mem = 8192
effective_cache_size = 234881024
random_page_cost = 2
(everything else is default)
The error message in the log is:
Jun 10 17:20:04 cruisecontrol-rhea postgres[6856]: [6-1] ERROR: 53200:
out of memory
Jun 10 17:20:04 cruisecontrol-rhea postgres[6856]: [6-2] DETAIL: Failed
on request of size 208.
Jun 10 17:20:04 cruisecontrol-rhea postgres[6856]: [6-3] LOCATION:
AllocSetAlloc, aset.c:700
All failures are with the following query (again, it only fails every
now and then). The query returns only a few results:
STATEMENT: SELECT
Tracker_Artifact0.id AS id,
Tracker_Artifact0.priority AS priority,
Tracker_Artifact_extension_f1.path AS projectPathString,
Tracker_Artifact_extension_f1.title AS projectTitle,
Tracker_Artifact_extension_f0.project_id AS projectId,
Tracker_Artifact_extension_f0.path AS folderPathString,
Tracker_Artifact_extension_f0.title AS folderTitle,
Tracker_Artifact_extension0.folder_id AS folderId,
Tracker_Artifact_extension0.title AS title,
Tracker_Artifact_extension0.name AS name,
Tracker_Artifact0.description AS description,
Tracker_Artifact_group0.value AS artifactGroup,
Tracker_Artifact_status0.value AS status,
Tracker_Artifact_status0.value_class AS statusClass,
Tracker_Artifact_category0.value AS category,
Tracker_Artifact_customer0.value AS customer,
Tracker_Artifact_extension_c0.username AS submittedByUsername,
Tracker_Artifact_extension_c0.full_name AS submittedByFullname,
Tracker_Artifact_extension0.date_created AS submittedDate,
Tracker_Artifact0.close_date AS closeDate,
Tracker_Artifact_ArtifactAss0.username AS assignedToUsername,
Tracker_Artifact_ArtifactAss0.full_name AS assignedToFullname,
Tracker_Artifact_extension0.date_last_modified AS lastModifiedDate,
Tracker_Artifact0.estimated_hours AS estimatedHours,
Tracker_Artifact0.actual_hours AS actualHours,
Tracker_Artifact_extension0.version AS version
FROM
field_value Tracker_Artifact_group0,
item Tracker_Artifact_extension0,
relationship Tracker_Artifact_relation_Ar0,
sfuser Tracker_Artifact_ArtifactAss0,
field_value Tracker_Artifact_status0,
field_value Tracker_Artifact_category0,
field_value Tracker_Artifact_customer0,
folder Tracker_Artifact_extension_f0,
artifact Tracker_Artifact0,
project Tracker_Artifact_extension_f1,
sfuser Tracker_Artifact_extension_c0
WHERE
Tracker_Artifact0.id=Tracker_Artifact_extension0.id
AND
Tracker_Artifact_extension0.folder_id=Tracker_Artifact_extension_f0.id
AND
Tracker_Artifact_extension_f0.project_id=Tracker_Artifact_extension_f1.id
AND Tracker_Artifact0.group_fv=Tracker_Artifact_group0.id
AND Tracker_Artifact0.status_fv=Tracker_Artifact_status0.id
AND Tracker_Artifact0.category_fv=Tracker_Artifact_category0.id
AND Tracker_Artifact0.customer_fv=Tracker_Artifact_customer0.id
AND
Tracker_Artifact_extension0.created_by_id=Tracker_Artifact_extension_c0.id
AND Tracker_Artifact_relation_Ar0.is_deleted=false
AND
Tracker_Artifact_relation_Ar0.relationship_type_name='ArtifactAssignment'
AND
Tracker_Artifact_relation_Ar0.origin_id=Tracker_Artifact_ArtifactAss0.id
AND Tracker_Artifact0.id=Tracker_Artifact_relation_Ar0.target_id
AND (Tracker_Artifact_extension_f1.path='projects' OR
Tracker_Artifact_extension_f1.path LIKE 'projects.%')
AND Tracker_Artifact_extension0.is_deleted=false
AND Tracker_Artifact_status0.value_class='Open'
AND Tracker_Artifact_ArtifactAss0.username='foundr12622313'
ORDER BY
priority ASC,
lastModifiedDate DESC
Can anyone see anything dangerous about this query? What's the best way
to analyze this further?
Thanks
MarkS
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: [GENERAL] out of memory error
@ 2004-06-11 08:02 Richard Huxton <dev@archonet.com>
parent: Mark Striebeck <mstriebeck@vasoftware.com>
1 sibling, 0 replies; 42+ messages in thread
From: Richard Huxton @ 2004-06-11 08:02 UTC (permalink / raw)
To: Mark Striebeck <mstriebeck@vasoftware.com>; +Cc: pgsql-admin; pgsql-general@postgresql.org
Mark Striebeck wrote:
> Hi,
>
> we are using Postgres with a J2EE application (JBoss) and get
> intermittent "out of memory" errors on the Postgres database. We are
> running on a fairly large Linux server (Dual 3GHz, 2GB Ram) with the
> following parameters:
>
> shared_buffers = 8192
> sort_mem = 8192
> effective_cache_size = 234881024
> random_page_cost = 2
The effective_cache_size is measured in disk-blocks not bytes, so you'll
want to reduce that. It should be whatever the typical "cached" readout
of top is, divided by 8k.
> (everything else is default)
>
> The error message in the log is:
>
> Jun 10 17:20:04 cruisecontrol-rhea postgres[6856]: [6-1] ERROR: 53200:
> out of memory
> Jun 10 17:20:04 cruisecontrol-rhea postgres[6856]: [6-2] DETAIL: Failed
> on request of size 208.
> Jun 10 17:20:04 cruisecontrol-rhea postgres[6856]: [6-3] LOCATION:
> AllocSetAlloc, aset.c:700
What is the system's overall memory usage at this time? Is there one
postgresql backend using all this memory?
> All failures are with the following query (again, it only fails every
> now and then). The query returns only a few results:
[snip]
> Can anyone see anything dangerous about this query?
The only thing that struck me was you had 11 tables in the join which
means the geqo query-planner will kick in (assuming default config
values). If you can reproduce it regularly, you could try increasing
geqo_threshold and see if that had any effect.
> What's the best way to analyze this further?
1. Monitor memory usage when you run the query, see which process is
using what.
2. Get EXPLAIN ANALYSE for that query, there may be something unusual in
the plan.
3. Finally, might have to attach a debugger to a backend, but we'll need
to know what to look for first.
--
Richard Huxton
Archonet Ltd
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: [GENERAL] out of memory error
@ 2004-06-11 11:48 Martin Marques <martin@bugs.unl.edu.ar>
parent: Mark Striebeck <mstriebeck@vasoftware.com>
1 sibling, 0 replies; 42+ messages in thread
From: Martin Marques @ 2004-06-11 11:48 UTC (permalink / raw)
To: Mark Striebeck <mstriebeck@vasoftware.com>; +Cc: pgsql-general@postgresql.org; pgsql-admin
El Jue 10 Jun 2004 22:14, escribió:
> Hi,
>
> we are using Postgres with a J2EE application (JBoss) and get
> intermittent "out of memory" errors on the Postgres database. We are
> running on a fairly large Linux server (Dual 3GHz, 2GB Ram) with the
> following parameters:
>
> shared_buffers = 8192
This is very low for a 2GB server. Unless the server is overdimensioned. Think
that those 8192 are about 64 MB, and you have 2000 MB of fisical memory.
Also check that query which is hugh, and has to many unions.
--
08:40:02 up 27 days, 18:51, 1 user, load average: 1.16, 1.07, 0.75
-----------------------------------------------------------------
Martín Marqués | select 'mmarques' || '@' || 'unl.edu.ar'
Centro de Telematica | DBA, Programador, Administrador
Universidad Nacional
del Litoral
-----------------------------------------------------------------
^ permalink raw reply [nested|flat] 42+ messages in thread
* Out of memory error
@ 2004-06-15 20:24 ow <oneway_111@yahoo.com>
0 siblings, 1 reply; 42+ messages in thread
From: ow @ 2004-06-15 20:24 UTC (permalink / raw)
To: pgsql-admin
pg 7.4.2 on RH 7.3
Hi,
Am getting "Out of memory error" and pgSql is getting killed when running the
following statement in psql:
insert into tableA
select * from tableB
where testdate >= '2000-01-01' and testdate <= '2002-12-31'
TableB contains about 120 million records. The insert/select affects about
30-40M.
What's happening is that pgSql gradually takes all (well, almost) physical and
swap memory and then, I think, is getting killed by the kernel.
Qs:
1) Is this normal?
2) Is there anything I can do besides adding more memory to the box?
Thanks
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Out of memory error
@ 2004-06-16 01:39 Tom Lane <tgl@sss.pgh.pa.us>
parent: ow <oneway_111@yahoo.com>
0 siblings, 0 replies; 42+ messages in thread
From: Tom Lane @ 2004-06-16 01:39 UTC (permalink / raw)
To: ow <oneway_111@yahoo.com>; +Cc: pgsql-admin
ow <oneway_111@yahoo.com> writes:
> insert into tableA
> select * from tableB
> where testdate >= '2000-01-01' and testdate <= '2002-12-31'
> What's happening is that pgSql gradually takes all (well, almost) physical and
> swap memory and then, I think, is getting killed by the kernel.
> 1) Is this normal?
No.
Perhaps you have a bunch of triggers (including foreign-key checks) on
tableA? If so it'd probably be best to drop them temporarily.
The only reason I can think for this to eat memory is if the
pending-trigger-events queue is growing ...
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* out of memory error
@ 2005-03-26 04:07 pginfo <pginfo@t1.unisoftbg.com>
0 siblings, 1 reply; 42+ messages in thread
From: pginfo @ 2005-03-26 04:07 UTC (permalink / raw)
To: pgsql-admin
Hi ,
I try to make insert into myTable select .... on pg 8.0.1 and freeBSD 5.3.
After ~10 sec. pg returns "out of memory".
In log file I found:
Portal hash: 8192 total in 1 blocks; 2008 free (0 chunks); 6184 used
Relcache by OID: 8192 total in 1 blocks; 4040 free (0 chunks); 4152 used
Relcache by name: 24576 total in 2 blocks; 13240 free (5 chunks); 11336 used
LockTable (locallock hash): 8192 total in 1 blocks; 4056 free (0
chunks); 4136 u
sed
ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
ERROR: out of memory
DETAIL: Failed on request of size 340.
I have 2Gb RAM on this box.
regards,
ivan.
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2005-03-26 10:49 pginfo <pginfo@t1.unisoftbg.com>
parent: pginfo <pginfo@t1.unisoftbg.com>
0 siblings, 0 replies; 42+ messages in thread
From: pginfo @ 2005-03-26 10:49 UTC (permalink / raw)
To: pginfo <pginfo@t1.unisoftbg.com>; +Cc: pgsql-admin
Hi,
I send some additional info :
pginfo wrote:sklad05=# explain analyze select
S.IDS_NUM,S.IDS_SKLAD,SUM(S.KOL),S.sernum FROM A_GAR_PROD_R S where ids
< 9742465 GROUP BY S.IDS_NUM,S.IDS_SKLAD ,s.sernum limit 10;
QUERY
PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=82281.59..82281.61 rows=10 width=148) (actual
time=9373.301..9373.368 rows=10 loops=1)
-> HashAggregate (cost=82281.59..82594.48 rows=125156 width=148)
(actual time=9373.294..9373.328 rows=10 loops=1)
-> Index Scan using a_gar_prod_r_pkey on a_gar_prod_r s
(cost=0.00..69766.02 rows=1251557 width=148) (actual
time=16.412..4175.948 rows=1237554 loops=1)
Index Cond: (ids < 9742465)
Total runtime: 9386.082 ms
(5 rows)
sklad05=# explain analyze select
S.IDS_NUM,S.IDS_SKLAD,SUM(S.KOL),S.sernum FROM A_GAR_PROD_R S where ids
< 9742466 GROUP BY S.IDS_NUM,S.IDS_SKLAD ,s.sernum limit 10;
ERROR: out of memory
DETAIL: Failed on request of size 344.
sklad05=# explain analyze select
S.IDS_NUM,S.IDS_SKLAD,SUM(S.KOL),S.sernum FROM A_GAR_PROD_R S where ids
>= 9742466 GROUP BY S.IDS_NUM,S.IDS_SKLAD ,s.sernum limit 10;
QUERY
PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=7747.82..7747.84 rows=10 width=148) (actual
time=960.984..961.050 rows=10 loops=1)
-> HashAggregate (cost=7747.82..7777.27 rows=11783 width=148)
(actual time=960.979..961.011 rows=10 loops=1)
-> Index Scan using a_gar_prod_r_pkey on a_gar_prod_r s
(cost=0.00..6569.60 rows=117822 width=148) (actual time=0.874..431.357
rows=131824 loops=1)
Index Cond: (ids >= 9742466)
Total runtime: 961.283 ms
(5 rows)
regards,
ivan.
> Hi ,
> I try to make insert into myTable select .... on pg 8.0.1 and freeBSD
> 5.3.
> After ~10 sec. pg returns "out of memory".
>
> In log file I found:
>
> Portal hash: 8192 total in 1 blocks; 2008 free (0 chunks); 6184 used
> Relcache by OID: 8192 total in 1 blocks; 4040 free (0 chunks); 4152 used
> Relcache by name: 24576 total in 2 blocks; 13240 free (5 chunks);
> 11336 used
> LockTable (locallock hash): 8192 total in 1 blocks; 4056 free (0
> chunks); 4136 u
> sed
> ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
> ERROR: out of memory
> DETAIL: Failed on request of size 340.
>
> I have 2Gb RAM on this box.
>
> regards,
> ivan.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
^ permalink raw reply [nested|flat] 42+ messages in thread
* Out of memory error
@ 2006-06-23 17:05 Abu Mushayeed <amushayeed@hotmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Abu Mushayeed @ 2006-06-23 17:05 UTC (permalink / raw)
To: pgsql-admin
Hello,
I am running the following query:
SELECT
indiv_fkey,
MAX(emp_ind),
MAX(prizm_cd_indiv),
MAX(CASE
WHEN div IS NULL THEN NULL
WHEN store_loyal_loc_cd IS NULL THEN NULL
ELSE div || '-' || store_loyal_loc_cd
END) ,
MAX(supp_all_adv_ind) ,
MAX(supp_direct_mail_ind)
FROM
cdm.cdm_fedcustomer
WHERE
kept_acct_flg = 'Y' AND indiv_fkey IS NOT NULL
GROUP BY
indiv_fkey;
AFTER A WHILE THE SYSTEM COMES BACK AND SAYS IN THE LOG FILE:
TopMemoryContext: 45592 total in 4 blocks; 4600 free (14 chunks); 40992 used
TopTransactionContext: 8192 total in 1 blocks; 8136 free (0 chunks); 56 used
DeferredTriggerXact: 0 total in 0 blocks; 0 free (0 chunks); 0 used
MessageContext: 57344 total in 3 blocks; 23312 free (1 chunks); 34032 used
PortalMemory: 8192 total in 1 blocks; 8040 free (0 chunks); 152 used
PortalHeapMemory: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
ExecutorState: 24576 total in 2 blocks; 7416 free (3 chunks); 17160 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
AggContext: -1501569024 total in 351 blocks; 69904 free (507 chunks);
-1501638928 used
DynaHashTable: 302047256 total in 46 blocks; 275720 free (66 chunks);
301771536 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
CacheMemoryContext: 516096 total in 6 blocks; 114992 free (1 chunks); 401104
used
indiv_key_idx: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
fed_cust_indiv_sum_pk: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
cdm_fedcustomer_idx4: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
fedcust_lname_idx: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
fedcust_indivfkey_idx: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_attrdef_adrelid_adnum_index: 1024 total in 1 blocks; 320 free (0 chunks);
704 used
pg_database_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_database_datname_index: 1024 total in 1 blocks; 640 free (0 chunks); 384
used
pg_index_indrelid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384
used
pg_amop_opc_strategy_index: 1024 total in 1 blocks; 320 free (0 chunks); 704
used
pg_shadow_usename_index: 1024 total in 1 blocks; 640 free (0 chunks); 384
used
pg_amop_opr_opc_index: 1024 total in 1 blocks; 320 free (0 chunks); 704 used
pg_conversion_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384
used
pg_language_name_index: 1024 total in 1 blocks; 640 free (0 chunks); 384
used
pg_statistic_relid_att_index: 1024 total in 1 blocks; 320 free (0 chunks);
704 used
pg_attribute_relid_attnam_index: 1024 total in 1 blocks; 320 free (0
chunks); 704 used
pg_shadow_usesysid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384
used
pg_cast_source_target_index: 1024 total in 1 blocks; 320 free (0 chunks);
704 used
pg_conversion_name_nsp_index: 1024 total in 1 blocks; 320 free (0 chunks);
704 used
pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 320 free (0
chunks); 704 used
pg_namespace_nspname_index: 1024 total in 1 blocks; 640 free (0 chunks); 384
used
pg_conversion_default_index: 2048 total in 1 blocks; 704 free (0 chunks);
1344 used
pg_class_relname_nsp_index: 1024 total in 1 blocks; 320 free (0 chunks); 704
used
pg_aggregate_fnoid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384
used
pg_inherits_relid_seqno_index: 1024 total in 1 blocks; 320 free (0 chunks);
704 used
pg_language_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_type_typname_nsp_index: 1024 total in 1 blocks; 320 free (0 chunks); 704
used
pg_group_sysid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_namespace_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384
used
pg_proc_proname_args_nsp_index: 2048 total in 1 blocks; 704 free (0 chunks);
1344 used
pg_opclass_am_name_nsp_index: 2048 total in 1 blocks; 768 free (0 chunks);
1280 used
pg_group_name_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_proc_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_operator_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_amproc_opc_procnum_index: 1024 total in 1 blocks; 320 free (0 chunks);
704 used
pg_index_indexrelid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384
used
pg_operator_oprname_l_r_n_index: 2048 total in 1 blocks; 704 free (0
chunks); 1344 used
pg_opclass_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_rewrite_rel_rulename_index: 1024 total in 1 blocks; 320 free (0 chunks);
704 used
pg_type_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
pg_attribute_relid_attnum_index: 1024 total in 1 blocks; 320 free (0
chunks); 704 used
pg_class_oid_index: 1024 total in 1 blocks; 640 free (0 chunks); 384 used
MdSmgr: 8192 total in 1 blocks; 6000 free (0 chunks); 2192 used
DynaHash: 8192 total in 1 blocks; 6560 free (0 chunks); 1632 used
DynaHashTable: 8192 total in 1 blocks; 2008 free (0 chunks); 6184 used
DynaHashTable: 8192 total in 1 blocks; 5080 free (0 chunks); 3112 used
DynaHashTable: 8192 total in 1 blocks; 2008 free (0 chunks); 6184 used
DynaHashTable: 8192 total in 1 blocks; 1984 free (0 chunks); 6208 used
DynaHashTable: 8192 total in 1 blocks; 3520 free (0 chunks); 4672 used
DynaHashTable: 24576 total in 2 blocks; 13240 free (4 chunks); 11336 used
DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
DynaHashTable: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
2006-06-23 09:27:52 [27143] ERROR: out of memory
DETAIL: Failed on request of size 420.
STATEMENT: --INSERT INTO cdm_epiphany.fed_cust_indiv_summary_staging
SELECT
indiv_fkey,
MAX(emp_ind),
MAX(prizm_cd_indiv),
MAX(CASE
WHEN div IS NULL THEN NULL
WHEN store_loyal_loc_cd IS NULL THEN NULL
ELSE div || '-' || store_loyal_loc_cd
END) ,
MAX(supp_all_adv_ind) ,
MAX(supp_direct_mail_ind)
FROM
cdm.cdm_fedcustomer
WHERE
kept_acct_flg = 'Y' AND indiv_fkey IS NOT NULL
GROUP BY
indiv_fkey;
===================================================================================================================
BUT WHEN I RAN THE FOLLOWING QUERY IT CAME BACK WITH THE COUNT. I DID AN
EXPLAIN AND IT IS DOING A FULL TABLE SCAN WITH AN AGGREAGATE, BUT IN THE
ABOVE QUERY IT IS DOING A FULL TABLE SCAN AND A HASH AGGREGATE TO GET TO THE
RESULT.
SELECT
count(*)
/*
indiv_fkey,
MAX(emp_ind),
MAX(prizm_cd_indiv),
MAX(CASE
WHEN div IS NULL THEN NULL
WHEN store_loyal_loc_cd IS NULL THEN NULL
ELSE div || '-' || store_loyal_loc_cd
END) ,
MAX(supp_all_adv_ind) ,
MAX(supp_direct_mail_ind)
*/
FROM
cdm.cdm_fedcustomer
WHERE
kept_acct_flg = 'Y' AND indiv_fkey IS NOT NULL
--GROUP BY
-- indiv_fkey;
I AM NEW TO POSTGRES AND I WOULD LIKE TO KNOW HOW TO FIX THIS ISSUE.
Thanks
Abu
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: Out of memory error
@ 2006-06-23 17:18 Tom Lane <tgl@sss.pgh.pa.us>
parent: Abu Mushayeed <amushayeed@hotmail.com>
0 siblings, 0 replies; 42+ messages in thread
From: Tom Lane @ 2006-06-23 17:18 UTC (permalink / raw)
To: Abu Mushayeed <amushayeed@hotmail.com>; +Cc: pgsql-admin
"Abu Mushayeed" <amushayeed@hotmail.com> writes:
> AFTER A WHILE THE SYSTEM COMES BACK AND SAYS IN THE LOG FILE:
Please turn off your caps lock key :-(
> AggContext: -1501569024 total in 351 blocks; 69904 free (507 chunks);
> -1501638928 used
> DynaHashTable: 302047256 total in 46 blocks; 275720 free (66 chunks);
> 301771536 used
Hm, it's evidently misjudging how much memory will be needed by a
HashAggregate plan, probably because it's underestimating the number
of GROUP BY groups. Could we see the EXPLAIN output for the query?
What PG version is this exactly? Have you ANALYZEd the table lately?
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* out of memory error
@ 2010-08-05 13:01 Silvio Brandani <silvio.brandani@tech.sdb.it>
0 siblings, 3 replies; 42+ messages in thread
From: Silvio Brandani @ 2010-08-05 13:01 UTC (permalink / raw)
To: pgsql-admin
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.
--
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-08-05 13:22 Victor Hugo <vh.clemente@gmail.com>
parent: Silvio Brandani <silvio.brandani@tech.sdb.it>
2 siblings, 1 reply; 42+ messages in thread
From: Victor Hugo @ 2010-08-05 13:22 UTC (permalink / raw)
To: Silvio Brandani <silvio.brandani@tech.sdb.it>; +Cc: pgsql-admin
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 <silvio.brandani@tech.sdb.it>:
> 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
>
--
[]´s
Victor Hugo
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-08-05 14:03 Kevin Grittner <Kevin.Grittner@wicourts.gov>
parent: Silvio Brandani <silvio.brandani@tech.sdb.it>
2 siblings, 1 reply; 42+ messages in thread
From: Kevin Grittner @ 2010-08-05 14:03 UTC (permalink / raw)
To: pgsql-admin; Silvio Brandani <silvio.brandani@tech.sdb.it>
Silvio Brandani <silvio.brandani@tech.sdb.it> 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? (Sample of `vmstat 1` at
different points are good, if your OS supports that.)
> any suggestion ?
Read this page and post again with more detail:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-08-05 14:10 Silvio Brandani <silvio.brandani@tech.sdb.it>
parent: Victor Hugo <vh.clemente@gmail.com>
0 siblings, 1 reply; 42+ messages in thread
From: Silvio Brandani @ 2010-08-05 14:10 UTC (permalink / raw)
To: Victor Hugo <vh.clemente@gmail.com>; +Cc: pgsql-admin
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 <silvio.brandani@tech.sdb.it>:
>
>> 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.
--
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-08-05 14:15 Tom Lane <tgl@sss.pgh.pa.us>
parent: Kevin Grittner <Kevin.Grittner@wicourts.gov>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2010-08-05 14:15 UTC (permalink / raw)
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>; +Cc: pgsql-admin@postgresql.org, "Silvio Brandani" <silvio.brandani@tech.sdb.it>
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Silvio Brandani <silvio.brandani@tech.sdb.it> 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
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-08-05 14:29 Silvio Brandani <silvio.brandani@tech.sdb.it>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Silvio Brandani @ 2010-08-05 14:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>; pgsql-admin
Tom Lane ha scritto:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>
>> Silvio Brandani <silvio.brandani@tech.sdb.it> 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
<m_cli_x1>: 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); 1328 used
pg_statistic_relid_att_index: 3072 total in 2 blocks; 1600 free (2
chunks); 1472 used
pg_ts_dict_dictname_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_namespace_nspname_index: 3072 total in 2 blocks; 1696 free (2
chunks); 1376 used
pg_opfamily_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks);
1328 used
pg_opclass_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_ts_parser_prsname_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_amop_fam_strat_index: 3072 total in 2 blocks; 1384 free (2
chunks); 1688 used
pg_opclass_am_name_nsp_index: 3072 total in 2 blocks; 1576 free (3
chunks); 1496 used
pg_trigger_tgrelid_tgname_index: 3072 total in 2 blocks; 1600 free
(2 chunks); 1472 used
pg_cast_source_target_index: 3072 total in 2 blocks; 1600 free (2
chunks); 1472 used
pg_auth_members_role_member_index: 3072 total in 2 blocks; 1648 free
(2 chunks); 1424 used
pg_attribute_relid_attnum_index: 3072 total in 2 blocks; 1600 free
(2 chunks); 1472 used
pg_ts_config_cfgname_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_authid_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_ts_config_oid_index: 3072 total in 2 blocks; 1744 free (3
chunks); 1328 used
pg_conversion_default_index: 3072 total in 2 blocks; 1432 free (3
chunks); 1640 used
pg_language_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks);
1328 used
pg_enum_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks);
1328 used
pg_proc_proname_args_nsp_index: 3072 total in 2 blocks; 1576 free (3
chunks); 1496 used
pg_ts_parser_oid_index: 3072 total in 2 blocks; 1744 free (3
chunks); 1328 used
pg_database_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_conversion_name_nsp_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_class_relname_nsp_index: 3072 total in 2 blocks; 1600 free (2
chunks); 1472 used
pg_attribute_relid_attnam_index: 3072 total in 2 blocks; 1648 free
(2 chunks); 1424 used
pg_class_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_amproc_fam_proc_index: 3072 total in 2 blocks; 1384 free (2
chunks); 1688 used
pg_operator_oprname_l_r_n_index: 3072 total in 2 blocks; 1384 free
(2 chunks); 1688 used
pg_index_indexrelid_index: 3072 total in 2 blocks; 1696 free (2
chunks); 1376 used
pg_type_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_rewrite_rel_rulename_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_authid_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; 5792 free (0 chunks); 2400 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
2010-08-05 15:20:00 CEST [10349]: [262-1] ERROR: out of memory
2010-08-05 15:20:00 CEST [10349]: [263-1] DETAIL: Failed on request of
size 16.
The query:
BEGIN;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(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(tipmer.descripcio) ::char(31) as
Comm_Group,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.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,m_cli fab,m_cli agent,m_aeropu aer_l,m_aeropu
aer_d,m_merca merca,oe_vessel_t oev,m_cianav cia,m_cianav
cia2,m_tipmer tipmer,m_zonmar zmar,m_zonmar zmar2,m_zonmar
zmar3,m_zonmar zmar4,oe_vessel_imbarco oevi
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 '7/1/2010' AND '7/31/2010' AND
oes.cod_des = cons.codigo 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.tip_mer = merca.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 merca.grupo=tipmer.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
GROUP BY oes.azienda,oes.booking_nr,oem.progr_ctnr
linux cento5 64 bit with 8G ram .
when run teh query the cpu go to 100% and the memory go high to 8G then
the out of memory
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.
--
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-08-05 15:18 Tom Lane <tgl@sss.pgh.pa.us>
parent: Silvio Brandani <silvio.brandani@tech.sdb.it>
0 siblings, 0 replies; 42+ messages in thread
From: Tom Lane @ 2010-08-05 15:18 UTC (permalink / raw)
To: Silvio Brandani <silvio.brandani@tech.sdb.it>; +Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>; pgsql-admin
Silvio Brandani <silvio.brandani@tech.sdb.it> writes:
>> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>>> What query?
[ query with aggregates and GROUP BY ]
Does EXPLAIN show that it's trying to use a hash aggregation plan?
If so, try turning off enable_hashagg. I think the hash table might
be ballooning far past the number of entries the planner expected.
Do you have an idea how many groups there should be in the query
result?
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-08-05 16:13 Scott Marlowe <scott.marlowe@gmail.com>
parent: Silvio Brandani <silvio.brandani@tech.sdb.it>
0 siblings, 0 replies; 42+ messages in thread
From: Scott Marlowe @ 2010-08-05 16:13 UTC (permalink / raw)
To: Silvio Brandani <silvio.brandani@tech.sdb.it>; +Cc: Victor Hugo <vh.clemente@gmail.com>; pgsql-admin
2010/8/5 Silvio Brandani <silvio.brandani@tech.sdb.it>:
>>
>
> 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
That's usually the opposite of what you want to do here.
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-08-05 17:39 Bob Lunney <bob_lunney@yahoo.com>
parent: Silvio Brandani <silvio.brandani@tech.sdb.it>
2 siblings, 1 reply; 42+ messages in thread
From: Bob Lunney @ 2010-08-05 17:39 UTC (permalink / raw)
To: pgsql-admin@postgresql.org, Silvio Brandani <silvio.brandani@tech.sdb.it>
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 <silvio.brandani@tech.sdb.it> wrote:
> From: Silvio Brandani <silvio.brandani@tech.sdb.it>
> 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
>
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-08-06 08:13 Silvio Brandani <silvio.brandani@tech.sdb.it>
parent: Bob Lunney <bob_lunney@yahoo.com>
0 siblings, 1 reply; 42+ messages in thread
From: Silvio Brandani @ 2010-08-06 08:13 UTC (permalink / raw)
To: Bob Lunney <bob_lunney@yahoo.com>; +Cc: pgsql-admin
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 <silvio.brandani@tech.sdb.it> wrote:
>
>
>> From: Silvio Brandani <silvio.brandani@tech.sdb.it>
>> 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.
--
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-08-06 11:56 Silvio Brandani <silvio.brandani@tech.sdb.it>
parent: Silvio Brandani <silvio.brandani@tech.sdb.it>
0 siblings, 2 replies; 42+ messages in thread
From: Silvio Brandani @ 2010-08-06 11:56 UTC (permalink / raw)
To: Silvio Brandani <silvio.brandani@tech.sdb.it>; +Cc: pgsql-admin
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 <silvio.brandani@tech.sdb.it> wrote:
>>
>>
>>> From: Silvio Brandani <silvio.brandani@tech.sdb.it>
>>> 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.
--
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-08-06 15:43 Alvaro Herrera <alvherre@commandprompt.com>
parent: Silvio Brandani <silvio.brandani@tech.sdb.it>
1 sibling, 0 replies; 42+ messages in thread
From: Alvaro Herrera @ 2010-08-06 15:43 UTC (permalink / raw)
To: Silvio Brandani <silvio.brandani@tech.sdb.it>; +Cc: pgsql-admin
Excerpts from Silvio Brandani's message of vie ago 06 07:56:53 -0400 2010:
> 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???
If this is a prepared query, then that is a good guess. You can see the
real plan that the application is getting in psql by explaining the
execution of a prepared statement like this:
PREPARE foo(int, text) AS SELECT blah FROM foo, bar WHERE foo.id = $1 AND ...
EXPLAIN ANALYZE EXECUTE foo(someval, another);
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-09-02 12:50 Silvio Brandani <silvio.brandani@tech.sdb.it>
parent: Silvio Brandani <silvio.brandani@tech.sdb.it>
1 sibling, 1 reply; 42+ messages in thread
From: Silvio Brandani @ 2010-09-02 12:50 UTC (permalink / raw)
To: pgsql-admin
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
<m_cli_x1>: 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_toast_2619_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); 1328 used
pg_statistic_relid_att_index: 3072 total in 2 blocks; 1600 free (2
chunks); 1472 used
pg_ts_dict_dictname_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_namespace_nspname_index: 3072 total in 2 blocks; 1696 free (2
chunks); 1376 used
pg_opfamily_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks);
1328 used
pg_opclass_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_ts_parser_prsname_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_amop_fam_strat_index: 3072 total in 2 blocks; 1384 free (2
chunks); 1688 used
pg_opclass_am_name_nsp_index: 3072 total in 2 blocks; 1576 free (3
chunks); 1496 used
pg_trigger_tgrelid_tgname_index: 3072 total in 2 blocks; 1600 free
(2 chunks); 1472 used
pg_cast_source_target_index: 3072 total in 2 blocks; 1600 free (2
chunks); 1472 used
pg_auth_members_role_member_index: 3072 total in 2 blocks; 1648 free
(2 chunks); 1424 used
pg_attribute_relid_attnum_index: 3072 total in 2 blocks; 1600 free
(2 chunks); 1472 used
pg_ts_config_cfgname_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_authid_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_ts_config_oid_index: 3072 total in 2 blocks; 1744 free (3
chunks); 1328 used
pg_conversion_default_index: 3072 total in 2 blocks; 1432 free (3
chunks); 1640 used
pg_language_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks);
1328 used
pg_enum_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks);
1328 used
pg_proc_proname_args_nsp_index: 3072 total in 2 blocks; 1576 free (3
chunks); 1496 used
pg_ts_parser_oid_index: 3072 total in 2 blocks; 1744 free (3
chunks); 1328 used
pg_database_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_conversion_name_nsp_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_class_relname_nsp_index: 3072 total in 2 blocks; 1600 free (2
chunks); 1472 used
pg_attribute_relid_attnam_index: 3072 total in 2 blocks; 1648 free
(2 chunks); 1424 used
pg_class_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_amproc_fam_proc_index: 3072 total in 2 blocks; 1384 free (2
chunks); 1688 used
pg_operator_oprname_l_r_n_index: 3072 total in 2 blocks; 1384 free
(2 chunks); 1688 used
pg_index_indexrelid_index: 3072 total in 2 blocks; 1696 free (2
chunks); 1376 used
pg_type_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_rewrite_rel_rulename_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_authid_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.
--
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-09-02 13:37 Silvio Brandani <silvio.brandani@tech.sdb.it>
parent: Silvio Brandani <silvio.brandani@tech.sdb.it>
0 siblings, 1 reply; 42+ messages in thread
From: Silvio Brandani @ 2010-09-02 13:37 UTC (permalink / raw)
To: pgsql-admin; +Cc: Silvio Brandani <silvio.brandani@tech.sdb.it>
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
> <m_cli_x1>: 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_toast_2619_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); 1328 used
> pg_statistic_relid_att_index: 3072 total in 2 blocks; 1600 free (2
> chunks); 1472 used
> pg_ts_dict_dictname_index: 3072 total in 2 blocks; 1648 free (2
> chunks); 1424 used
> pg_namespace_nspname_index: 3072 total in 2 blocks; 1696 free (2
> chunks); 1376 used
> pg_opfamily_oid_index: 3072 total in 2 blocks; 1744 free (3
> chunks); 1328 used
> pg_opclass_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
> 1376 used
> pg_ts_parser_prsname_index: 3072 total in 2 blocks; 1648 free (2
> chunks); 1424 used
> pg_amop_fam_strat_index: 3072 total in 2 blocks; 1384 free (2
> chunks); 1688 used
> pg_opclass_am_name_nsp_index: 3072 total in 2 blocks; 1576 free (3
> chunks); 1496 used
> pg_trigger_tgrelid_tgname_index: 3072 total in 2 blocks; 1600 free
> (2 chunks); 1472 used
> pg_cast_source_target_index: 3072 total in 2 blocks; 1600 free (2
> chunks); 1472 used
> pg_auth_members_role_member_index: 3072 total in 2 blocks; 1648
> free (2 chunks); 1424 used
> pg_attribute_relid_attnum_index: 3072 total in 2 blocks; 1600 free
> (2 chunks); 1472 used
> pg_ts_config_cfgname_index: 3072 total in 2 blocks; 1648 free (2
> chunks); 1424 used
> pg_authid_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
> 1376 used
> pg_ts_config_oid_index: 3072 total in 2 blocks; 1744 free (3
> chunks); 1328 used
> pg_conversion_default_index: 3072 total in 2 blocks; 1432 free (3
> chunks); 1640 used
> pg_language_oid_index: 3072 total in 2 blocks; 1744 free (3
> chunks); 1328 used
> pg_enum_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks);
> 1328 used
> pg_proc_proname_args_nsp_index: 3072 total in 2 blocks; 1576 free
> (3 chunks); 1496 used
> pg_ts_parser_oid_index: 3072 total in 2 blocks; 1744 free (3
> chunks); 1328 used
> pg_database_oid_index: 3072 total in 2 blocks; 1696 free (2
> chunks); 1376 used
> pg_conversion_name_nsp_index: 3072 total in 2 blocks; 1648 free (2
> chunks); 1424 used
> pg_class_relname_nsp_index: 3072 total in 2 blocks; 1600 free (2
> chunks); 1472 used
> pg_attribute_relid_attnam_index: 3072 total in 2 blocks; 1648 free
> (2 chunks); 1424 used
> pg_class_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
> 1376 used
> pg_amproc_fam_proc_index: 3072 total in 2 blocks; 1384 free (2
> chunks); 1688 used
> pg_operator_oprname_l_r_n_index: 3072 total in 2 blocks; 1384 free
> (2 chunks); 1688 used
> pg_index_indexrelid_index: 3072 total in 2 blocks; 1696 free (2
> chunks); 1376 used
> pg_type_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
> 1376 used
> pg_rewrite_rel_rulename_index: 3072 total in 2 blocks; 1648 free (2
> chunks); 1424 used
> pg_authid_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
>
>
Postgres version is 8.3.8 x64bit under linux Centos, the driver odbc is
an 8.02.02.
Could be a problem with Postgres ODBC driver version ??
--
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.
--
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-09-02 14:27 Tom Lane <tgl@sss.pgh.pa.us>
parent: Silvio Brandani <silvio.brandani@tech.sdb.it>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2010-09-02 14:27 UTC (permalink / raw)
To: Silvio Brandani <silvio.brandani@tech.sdb.it>; +Cc: pgsql-admin
Silvio Brandani <silvio.brandani@tech.sdb.it> 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
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-09-02 15:05 Silvio Brandani <silvio.brandani@tech.sdb.it>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Silvio Brandani @ 2010-09-02 15:05 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-admin
Tom Lane ha scritto:
> Silvio Brandani <silvio.brandani@tech.sdb.it> 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.
--
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-09-02 15:09 Tom Lane <tgl@sss.pgh.pa.us>
parent: Silvio Brandani <silvio.brandani@tech.sdb.it>
0 siblings, 2 replies; 42+ messages in thread
From: Tom Lane @ 2010-09-02 15:09 UTC (permalink / raw)
To: Silvio Brandani <silvio.brandani@tech.sdb.it>; +Cc: pgsql-admin
Silvio Brandani <silvio.brandani@tech.sdb.it> 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
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-09-03 07:33 Silvio Brandani <silvio.brandani@tech.sdb.it>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 42+ messages in thread
From: Silvio Brandani @ 2010-09-03 07:33 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-admin
Tom Lane ha scritto:
> Silvio Brandani <silvio.brandani@tech.sdb.it> 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.
--
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2010-09-03 08:15 Silvio Brandani <silvio.brandani@tech.sdb.it>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 42+ messages in thread
From: Silvio Brandani @ 2010-09-03 08:15 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin
Tom Lane ha scritto:
> Silvio Brandani <silvio.brandani@tech.sdb.it> 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.
--
^ permalink raw reply [nested|flat] 42+ messages in thread
* out of memory error
@ 2012-05-22 16:44 Vincent Dautremont <vincent@searidgetech.com>
0 siblings, 1 reply; 42+ messages in thread
From: Vincent Dautremont @ 2012-05-22 16:44 UTC (permalink / raw)
To: pgsql-admin
H,
after a few days, i'm seeing the following logs in a database (postgresql
8.3.15 on Windows)
running with rubyrep 1.2.0 for syncing a few table small that have frequent
update / insert/ delete.
I don't understand it and I'd like to know what happens and why. How to get
rid of it.
I've seen in the same time from Windows Task Manager that the memory of a
postregres.exe process goes constantly up (I've seen it up to 1.4 GB) then
I suppose the process must crash since I can't see it anymore.
log :
---------------------
TopMemoryContext: 197681816 total in 24131 blocks; 394104 free (24179
chunks); 197287712 used
TopTransactionContext: 8192 total in 1 blocks; 7792 free (0 chunks); 400
used
PL/PgSQL function context: 8192 total in 1 blocks; 2912 free (3 chunks);
5280 used
PL/PgSQL function context: 8192 total in 1 blocks; 2912 free (3 chunks);
5280 used
PL/PgSQL function context: 8192 total in 1 blocks; 3168 free (4 chunks);
5024 used
PL/PgSQL function context: 8192 total in 1 blocks; 3168 free (4 chunks);
5024 used
PL/PgSQL function context: 8192 total in 1 blocks; 3184 free (4 chunks);
5008 used
PL/PgSQL function context: 8192 total in 1 blocks; 3184 free (4 chunks);
5008 used
RI compare cache: 8192 total in 1 blocks; 1800 free (0 chunks); 6392 used
RI query cache: 24576 total in 2 blocks; 14136 free (5 chunks); 10440 used
CFuncHash: 8192 total in 1 blocks; 4936 free (0 chunks); 3256 used
Rendezvous variable hash: 8192 total in 1 blocks; 3848 free (0 chunks);
4344 used
PLpgSQL function cache: 24328 total in 2 blocks; 5904 free (0 chunks);
18424 used
Type information cache: 8192 total in 1 blocks; 1800 free (0 chunks);
6392 used
Record information cache: 8192 total in 1 blocks; 1800 free (0 chunks);
6392 used
Prepared Queries: 8192 total in 1 blocks; 1800 free (0 chunks); 6392 used
Operator class cache: 8192 total in 1 blocks; 3848 free (0 chunks); 4344
used
Operator lookup cache: 24576 total in 2 blocks; 14072 free (6 chunks);
10504 used
MessageContext: 8192 total in 1 blocks; 7144 free (1 chunks); 1048 used
smgr relation table: 8192 total in 1 blocks; 1776 free (0 chunks); 6416
used
TransactionAbortContext: 32768 total in 1 blocks; 32752 free (0 chunks);
16 used
Portal hash: 8192 total in 1 blocks; 3912 free (0 chunks); 4280 used
PortalMemory: 8192 total in 1 blocks; 8040 free (0 chunks); 152 used
PortalHeapMemory: 4096 total in 1 blocks; 1888 free (0 chunks); 2208
used
ExecutorState: 122880 total in 4 blocks; 46296 free (5 chunks); 76584
used
TupleSort: 24600 total in 2 blocks; 7512 free (0 chunks); 17088 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
Relcache by OID: 8192 total in 1 blocks; 2856 free (0 chunks); 5336 used
CacheMemoryContext: 8531792 total in 24 blocks; 282000 free (617 chunks);
8249792 used
unnamed prepared statement: 253952 total in 5 blocks; 10664 free (7
chunks); 243288 used
unnamed prepared statement: 253952 total in 5 blocks; 86232 free (1
chunks); 167720 used
CachedPlan: 1024 total in 1 blocks; 576 free (0 chunks); 448 used
CachedPlanSource: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 248 free (0 chunks); 776 used
CachedPlanSource: 1024 total in 1 blocks; 96 free (0 chunks); 928 used
SPI Plan: 1024 total in 1 blocks; 928 free (0 chunks); 96 used
CachedPlan: 1024 total in 1 blocks; 576 free (0 chunks); 448 used
CachedPlanSource: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 248 free (0 chunks); 776 used
CachedPlanSource: 1024 total in 1 blocks; 96 free (0 chunks); 928 used
SPI Plan: 1024 total in 1 blocks; 928 free (0 chunks); 96 used
.
.
. there it goes for about 80MB of log then it ends
.
.
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 248 free (0 chunks); 776 used
CachedPlanSource: 1024 total in 1 blocks; 96 free (0 chunks); 928 used
SPI Plan: 1024 total in 1 blocks; 928 free (0 chunks); 96 used
CachedPlan: 1024 total in 1 blocks; 576 free (0 chunks); 448 used
CachedPlanSource: 1024 total in 1 blocks; 344 free (0 chunks); 680 used
SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
CachedPlan: 1024 total in 1 blocks; 248 free (0 chunks); 776 used
CachedPlanSource: 1024 total in 1 blocks; 96 free (0 chunks); 928 used
SPI Plan: 1024 total in 1 blocks; 928 free (0 chunks); 96 used
CachedPlan: 1024 total in 1 blocks; 904 free (0 chunks); 120 used
CachedPlanSource: 1024 total in 1 blocks; 840 free (0 chunks); 184 used
CachedPlan: 3072 total in 2 blocks; 392 free (0 chunks); 2680 used
CachedPlanSource: 3072 total in 2 blocks; 1904 free (1 chunks); 1168
used
CachedPlan: 7168 total in 3 blocks; 4080 free (1 chunks); 3088 used
CachedPlanSource: 3072 total in 2 blocks; 1384 free (0 chunks); 1688
used
pg_opclass_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720
used
pg_amop_fam_strat_index: 1024 total in 1 blocks; 88 free (0 chunks);
936 used
pg_trigger_tgrelid_tgname_index: 1024 total in 1 blocks; 240 free (0
chunks); 784 used
pg_attribute_relid_attnum_index: 1024 total in 1 blocks; 240 free (0
chunks); 784 used
pg_class_oid_index: 1024 total in 1 blocks; 304 free (0 chunks); 720
used
pg_amproc_fam_proc_index: 1024 total in 1 blocks; 88 free (0 chunks);
936 used
pg_index_indexrelid_index: 1024 total in 1 blocks; 304 free (0 chunks);
720 used
pg_rewrite_rel_rulename_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
MdSmgr: 8192 total in 1 blocks; 7288 free (6 chunks); 904 used
LOCALLOCK hash: 8192 total in 1 blocks; 1856 free (0 chunks); 6336 used
Timezones: 49432 total in 2 blocks; 5968 free (0 chunks); 43464 used
ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
2012-05-02 08:01:10 WET ERROR: out of memory
2012-05-02 08:01:10 WET DETAIL: Failed on request of size 8.
2012-05-02 08:01:10 WET STATEMENT: SELECT
n.nspname,c.relname,a.attname,a.atttypid,a.attnotnull,a.atttypmod,a.attlen,a.attnum,pg_catalog.pg_get_expr(def.adbin,
def.adrelid) AS adsrc,dsc.description,t.typbasetype,t.typtype FROM
pg_catalog.pg_namespace n JOIN pg_catalog.pg_class c ON (c.relnamespace =
n.oid) JOIN pg_catalog.pg_attribute a ON (a.attrelid=c.oid) JOIN
pg_catalog.pg_type t ON (a.atttypid = t.oid) LEFT JOIN
pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND a.attnum =
def.adnum) LEFT JOIN pg_catalog.pg_description dsc ON (c.oid=dsc.objoid
AND a.attnum = dsc.objsubid) LEFT JOIN pg_catalog.pg_class dc ON
(dc.oid=dsc.classoid AND dc.relname='pg_class') LEFT JOIN
pg_catalog.pg_namespace dn ON (dc.relnamespace=dn.oid AND
dn.nspname='pg_catalog') WHERE a.attnum > 0 AND NOT a.attisdropped AND
n.nspname LIKE 'public' AND c.relname LIKE 'rr_pending_changes' ORDER BY
nspname,c.relname,attnum
2012-05-02 08:01:10 WET LOG: could not send data to client: No connection
could be made because the target machine actively refused it.
2012-05-02 08:01:10 WET STATEMENT: SELECT
n.nspname,c.relname,a.attname,a.atttypid,a.attnotnull,a.atttypmod,a.attlen,a.attnum,pg_catalog.pg_get_expr(def.adbin,
def.adrelid) AS adsrc,dsc.description,t.typbasetype,t.typtype FROM
pg_catalog.pg_namespace n JOIN pg_catalog.pg_class c ON (c.relnamespace =
n.oid) JOIN pg_catalog.pg_attribute a ON (a.attrelid=c.oid) JOIN
pg_catalog.pg_type t ON (a.atttypid = t.oid) LEFT JOIN
pg_catalog.pg_attrdef def ON (a.attrelid=def.adrelid AND a.attnum =
def.adnum) LEFT JOIN pg_catalog.pg_description dsc ON (c.oid=dsc.objoid
AND a.attnum = dsc.objsubid) LEFT JOIN pg_catalog.pg_class dc ON
(dc.oid=dsc.classoid AND dc.relname='pg_class') LEFT JOIN
pg_catalog.pg_namespace dn ON (dc.relnamespace=dn.oid AND
dn.nspname='pg_catalog') WHERE a.attnum > 0 AND NOT a.attisdropped AND
n.nspname LIKE 'public' AND c.relname LIKE 'rr_pending_changes' ORDER BY
nspname,c.relname,attnum
2012-05-02 08:01:10 WET LOG: could not receive data from client: No
connection could be made because the target machine actively refused it.
---------------------
Thank you for hints about that.
Vincent.
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2012-05-22 17:33 Tom Lane <tgl@sss.pgh.pa.us>
parent: Vincent Dautremont <vincent@searidgetech.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2012-05-22 17:33 UTC (permalink / raw)
To: Vincent Dautremont <vincent@searidgetech.com>; +Cc: pgsql-admin
Vincent Dautremont <vincent@searidgetech.com> writes:
> after a few days, i'm seeing the following logs in a database (postgresql
> 8.3.15 on Windows)
> running with rubyrep 1.2.0 for syncing a few table small that have frequent
> update / insert/ delete.
> I don't understand it and I'd like to know what happens and why. How to get
> rid of it.
Well, this is a bit unusual:
> TopMemoryContext: 197681816 total in 24131 blocks; 394104 free (24179
> chunks); 197287712 used
It's not normal to have so much stuff in TopMemoryContext. That could
represent a leak, but it's also possible that that's just management
overhead for all of these contexts:
> SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
> CachedPlan: 1024 total in 1 blocks; 248 free (0 chunks); 776 used
> CachedPlanSource: 1024 total in 1 blocks; 96 free (0 chunks); 928 used
> SPI Plan: 1024 total in 1 blocks; 928 free (0 chunks); 96 used
> .
> .
> . there it goes for about 80MB of log then it ends
> .
> .
> SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
> CachedPlan: 1024 total in 1 blocks; 248 free (0 chunks); 776 used
> CachedPlanSource: 1024 total in 1 blocks; 96 free (0 chunks); 928 used
That's a *heck* of a lot of SPI plans. You haven't provided any
information that would let anybody diagnose why you have so many,
though. Tell us about your usage patterns, especially of PL-language
functions.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2012-05-22 18:04 Vincent Dautremont <vincent@searidgetech.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Vincent Dautremont @ 2012-05-22 18:04 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin
Well,
I think that i'm using the database for pretty basic stuffs.
It's mostly used with stored procedures to update/ insert / select a row of
each table.
On 3 tables (less than 10 rows each), clients does updates/select at 2Hz to
have pseudo real-time data up to date.
I've got a total of 6 clients to the DB, they all access DB using stored
procedures
I would say that this is a light usage of the DB.
Then I have rubyrep 1.2.0 running to sync a backup of the DB.
it syncs 8 tables : 7 of them doesn't really change often and 1 is one of
the pseudo real-time data one.
So everything works fine, but I see postgres process memory usage growing,
it can go about 1GB to 1.5GB in about 5to 6 days, then I suppose it crashes.
I don't know a lot about PostgreSQL, what does the TopMemoryContext means.
I haven't been able to find much information about it.
Is it like a global memory stack for the DB ?
I've tried using the default postgres.conf file I usually run this modified
one with these values.
------------------------
"version";"PostgreSQL 8.3.15, compiled by Visual C++ build 1400"
"autovacuum";"on"
"autovacuum_analyze_threshold";"50"
"autovacuum_max_workers";"3"
"autovacuum_naptime";"1min"
"autovacuum_vacuum_threshold";"50"
"client_encoding";"UNICODE"
"deadlock_timeout";"5s"
"effective_cache_size";"2GB"
"lc_collate";"English_United States.1252"
"lc_ctype";"English_United States.1252"
"listen_addresses";"*"
"log_destination";"stderr"
"log_filename";"postgresql-%Y-%m-%d.log"
"log_line_prefix";"%t "
"log_rotation_age";"1d"
"log_truncate_on_rotation";"on"
"logging_collector";"on"
"max_connections";"100"
"max_fsm_pages";"204800"
"max_stack_depth";"2MB"
"port";"5432"
"server_encoding";"UTF8"
"shared_buffers";"512MB"
"shared_preload_libraries";"$libdir/plugins/plugin_debugger.dll"
"TimeZone";"Africa/Casablanca"
"track_counts";"on"
------------------------
Thanks,
Vincent
On Tue, May 22, 2012 at 1:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Vincent Dautremont <vincent@searidgetech.com> writes:
> > after a few days, i'm seeing the following logs in a database
> (postgresql
> > 8.3.15 on Windows)
> > running with rubyrep 1.2.0 for syncing a few table small that have
> frequent
> > update / insert/ delete.
> > I don't understand it and I'd like to know what happens and why. How to
> get
> > rid of it.
>
> Well, this is a bit unusual:
>
> > TopMemoryContext: 197681816 total in 24131 blocks; 394104 free (24179
> > chunks); 197287712 used
>
> It's not normal to have so much stuff in TopMemoryContext. That could
> represent a leak, but it's also possible that that's just management
> overhead for all of these contexts:
>
> > SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
> > CachedPlan: 1024 total in 1 blocks; 248 free (0 chunks); 776 used
> > CachedPlanSource: 1024 total in 1 blocks; 96 free (0 chunks); 928
> used
> > SPI Plan: 1024 total in 1 blocks; 928 free (0 chunks); 96 used
>
> > .
> > .
> > . there it goes for about 80MB of log then it ends
> > .
> > .
> > SPI Plan: 1024 total in 1 blocks; 912 free (0 chunks); 112 used
> > CachedPlan: 1024 total in 1 blocks; 248 free (0 chunks); 776 used
> > CachedPlanSource: 1024 total in 1 blocks; 96 free (0 chunks); 928
> used
>
> That's a *heck* of a lot of SPI plans. You haven't provided any
> information that would let anybody diagnose why you have so many,
> though. Tell us about your usage patterns, especially of PL-language
> functions.
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2012-05-22 18:30 Tom Lane <tgl@sss.pgh.pa.us>
parent: Vincent Dautremont <vincent@searidgetech.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2012-05-22 18:30 UTC (permalink / raw)
To: Vincent Dautremont <vincent@searidgetech.com>; +Cc: pgsql-admin
Vincent Dautremont <vincent@searidgetech.com> writes:
> I think that i'm using the database for pretty basic stuffs.
> It's mostly used with stored procedures to update/ insert / select a row of
> each table.
> On 3 tables (less than 10 rows each), clients does updates/select at 2Hz to
> have pseudo real-time data up to date.
> I've got a total of 6 clients to the DB, they all access DB using stored
> procedures
> I would say that this is a light usage of the DB.
> Then I have rubyrep 1.2.0 running to sync a backup of the DB.
> it syncs 8 tables : 7 of them doesn't really change often and 1 is one of
> the pseudo real-time data one.
This is not much information. What I suspect is happening is that
you're using plpgsql functions (or some other PL) in such a way that the
system is leaking cached plans for the functions' queries; but there is
far from enough evidence here to prove or disprove that, let alone debug
the problem if that is a correct guess. An entirely blue-sky guess as
to what your code might be doing to trigger such a problem is if you
were constantly replacing the same function's definition via CREATE OR
REPLACE FUNCTION. But that could be totally wrong, too.
Can you put together a self-contained test case that triggers similar
growth in the server process size?
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2012-05-22 19:46 Vincent Dautremont <vincent@searidgetech.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Vincent Dautremont @ 2012-05-22 19:46 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin
Thanks Tom,
when you say,
> An entirely blue-sky guess as
> to what your code might be doing to trigger such a problem is if you
> were constantly replacing the same function's definition via CREATE OR
> REPLACE FUNCTION.
>
Do you mean that what would happen is that when we call the plpgsql
function, it executes each time a create or replace, then execute the
function ?
because my functions are all written like that :
-- Function: spzoneinsert(integer, integer)
> CREATE OR REPLACE FUNCTION spzoneinsert(i_zoneid integer, i_output_port
> integer)
> RETURNS void AS
> $BODY$
>
> BEGIN
> Begin
> INSERT INTO zone
> (zone_Id,
> output_port)
> VALUES
> (i_zoneID,
> i_Output_Port);
> End;
> END;
> $BODY$
> LANGUAGE 'plpgsql' VOLATILE
> COST 100;
> ALTER FUNCTION spzoneinsert(integer, integer) OWNER TO db_casd_admin_role;
> GRANT EXECUTE ON FUNCTION spzoneinsert(integer, integer) TO
> db_casd_admin_role;
>
Which is suppose is the normal way to write a function. I assume only the
partr between the $BODY$ are executed.
then this is called via ADODB in our C++ softwares.
I will try to run a DB without its client softwares, just both DBs with
rubyrep and a BAT script doing updates using one of my functions call at a
quicker rate than 2Hz. and'll monitor the memory usage and PG logs
Vincent.
On Tue, May 22, 2012 at 2:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Vincent Dautremont <vincent@searidgetech.com> writes:
> > I think that i'm using the database for pretty basic stuffs.
> > It's mostly used with stored procedures to update/ insert / select a row
> of
> > each table.
> > On 3 tables (less than 10 rows each), clients does updates/select at 2Hz
> to
> > have pseudo real-time data up to date.
> > I've got a total of 6 clients to the DB, they all access DB using stored
> > procedures
> > I would say that this is a light usage of the DB.
>
> > Then I have rubyrep 1.2.0 running to sync a backup of the DB.
> > it syncs 8 tables : 7 of them doesn't really change often and 1 is one of
> > the pseudo real-time data one.
>
> This is not much information. What I suspect is happening is that
> you're using plpgsql functions (or some other PL) in such a way that the
> system is leaking cached plans for the functions' queries; but there is
> far from enough evidence here to prove or disprove that, let alone debug
> the problem if that is a correct guess. An entirely blue-sky guess as
> to what your code might be doing to trigger such a problem is if you
> were constantly replacing the same function's definition via CREATE OR
> REPLACE FUNCTION. But that could be totally wrong, too.
>
> Can you put together a self-contained test case that triggers similar
> growth in the server process size?
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2012-05-22 20:04 Tom Lane <tgl@sss.pgh.pa.us>
parent: Vincent Dautremont <vincent@searidgetech.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2012-05-22 20:04 UTC (permalink / raw)
To: Vincent Dautremont <vincent@searidgetech.com>; +Cc: pgsql-admin
Vincent Dautremont <vincent@searidgetech.com> writes:
>> An entirely blue-sky guess as
>> to what your code might be doing to trigger such a problem is if you
>> were constantly replacing the same function's definition via CREATE OR
>> REPLACE FUNCTION.
> Do you mean that what would happen is that when we call the plpgsql
> function, it executes each time a create or replace, then execute the
> function ?
> because my functions are all written like that :
> -- Function: spzoneinsert(integer, integer)
>> CREATE OR REPLACE FUNCTION spzoneinsert(i_zoneid integer, i_output_port
>> integer)
>> RETURNS void AS
Well, yeah, that is the common way to define a function. The question
was about whether you are constantly re-executing this same SQL
thousands of times over the course of a session. I think it would take
actually using the function in between such redefinitions to provoke a
plan leak, but if you were doing that it might explain the problem.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2012-05-23 14:06 Vincent Dautremont <vincent@searidgetech.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Vincent Dautremont @ 2012-05-23 14:06 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin
Thanks,
So I've been able to find what's causing my postgres process memory amount
to grow, but I don't know why it happens.
So, my software is updating 6 rows/second on my main database.
Rubyrep is running on my server with thebackup database doing a "replicate"
The huge TopMemoryContext problem and memory size of the postgres process
are happening on my backup database.
I've found out that when my software does these updates the memory of the
postgres process grows constantly at 24 MB/hour. when I stop my software to
update these rows, the memory of the process stops to grow.
also I've noticed that when I stop rubyrep, this postgres process disappear.
I'm running rubyrep 1.2.0 and here is my rubyrep config file :
RR::Initializer::run do |config|
> config.left = { # main database
> :adapter => 'xxx',
> :database => 'yyy',
> :username => 'zzz',
> :password => 'ttt',
> :host => '10.97.14.102'
> }
>
> config.right = { # backup database
> :adapter => 'xxx',
> :database => 'yyy',
> :username => 'zzz',
> :password => 'ttt',
> :host => '10.97.14.101'
> }
>
> config.options[:sync_conflict_handling] = :right_wins
> config.options[:replication_conflict_handling] = :right_wins
> config.include_tables 'archiver'
> config.include_tables 'camera'
> config.include_tables 'cda'
> config.include_tables 'component_restart'
> config.include_tables 'operation_mode'
> config.include_tables 'ptz_lock'
> config.include_tables 'standby_table'
> config.include_tables 'video_output'
>
> end
>
I don't know what other information I could add to that.
Vincent.
On Tue, May 22, 2012 at 4:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Vincent Dautremont <vincent@searidgetech.com> writes:
> >> An entirely blue-sky guess as
> >> to what your code might be doing to trigger such a problem is if you
> >> were constantly replacing the same function's definition via CREATE OR
> >> REPLACE FUNCTION.
>
> > Do you mean that what would happen is that when we call the plpgsql
> > function, it executes each time a create or replace, then execute the
> > function ?
> > because my functions are all written like that :
>
> > -- Function: spzoneinsert(integer, integer)
> >> CREATE OR REPLACE FUNCTION spzoneinsert(i_zoneid integer, i_output_port
> >> integer)
> >> RETURNS void AS
>
> Well, yeah, that is the common way to define a function. The question
> was about whether you are constantly re-executing this same SQL
> thousands of times over the course of a session. I think it would take
> actually using the function in between such redefinitions to provoke a
> plan leak, but if you were doing that it might explain the problem.
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2012-05-23 15:26 Tom Lane <tgl@sss.pgh.pa.us>
parent: Vincent Dautremont <vincent@searidgetech.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2012-05-23 15:26 UTC (permalink / raw)
To: Vincent Dautremont <vincent@searidgetech.com>; +Cc: pgsql-admin
Vincent Dautremont <vincent@searidgetech.com> writes:
> I've found out that when my software does these updates the memory of the
> postgres process grows constantly at 24 MB/hour. when I stop my software to
> update these rows, the memory of the process stops to grow.
> also I've noticed that when I stop rubyrep, this postgres process disappear.
Hmm. I wondered whether rubyrep might be triggering this somehow;
I don't know anything about that software. I went so far as to download
rubyrep and look at the Postgres-specific source code yesterday. It
doesn't look like it's doing anything strange, but I could easily have
missed something.
One thing you could try doing is to turn on query logging (set
log_statement = all) and look to see if rubyrep, or some other part of
your system, is indeed issuing repeated CREATE OR REPLACE FUNCTION
commands.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2012-05-23 21:22 Vincent Dautremont <vincent@searidgetech.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 42+ messages in thread
From: Vincent Dautremont @ 2012-05-23 21:22 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin
Hi,
you were right,
I do see those CREATE OR REPLACE FUNCTION a bit more than 1 per second
(approx. 12 times for 10 seconds)
2012-05-23 21:15:45 WET LOG: execute <unnamed>: CREATE OR
> REPLACE FUNCTION "rr_ptz_lock"() RETURNS TRIGGER AS $change_trigger$
> BEGIN
> PERFORM ACTIVE FROM
> "public".rr_running_flags;
> IF FOUND THEN
> RETURN NULL;
> END IF;
>
> IF (TG_OP = 'DELETE') THEN
> INSERT INTO "public".rr_pending_changes(change_table,
> change_key, change_type, change_time)
> SELECT 'ptz_lock', 'workstation_id|' ||
> OLD."workstation_id" || '|' || 'camera_id|' || OLD."camera_id", 'D', now();
> ELSIF (TG_OP = 'UPDATE') THEN
>
> INSERT INTO "public".rr_pending_changes(change_table,
> change_key, change_new_key, change_type, change_time)
> SELECT 'ptz_lock', 'workstation_id|' ||
> OLD."workstation_id" || '|' || 'camera_id|' || OLD."camera_id",
> 'workstation_id|' || NEW."workstation_id" || '|' || 'camera_id|' ||
> NEW."camera_id", 'U', now();
> ELSIF (TG_OP = 'INSERT') THEN
> INSERT INTO "public".rr_pending_changes(change_table,
> change_key, change_type, change_time)
> SELECT 'ptz_lock', 'workstation_id|' ||
> NEW."workstation_id" || '|' || 'camera_id|' || NEW."camera_id", 'I', now();
> END IF;
> RETURN NULL; -- result is ignored since this is an AFTER
> trigger
> END;
> $change_trigger$ LANGUAGE plpgsql
>
I don't know a lot about the internal of rubyrep, but do you think this is
not a normal behaviour from a postgresql server point of view ?
Vincent.
On Wed, May 23, 2012 at 11:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Vincent Dautremont <vincent@searidgetech.com> writes:
> > I've found out that when my software does these updates the memory of the
> > postgres process grows constantly at 24 MB/hour. when I stop my software
> to
> > update these rows, the memory of the process stops to grow.
> > also I've noticed that when I stop rubyrep, this postgres process
> disappear.
>
> Hmm. I wondered whether rubyrep might be triggering this somehow;
> I don't know anything about that software. I went so far as to download
> rubyrep and look at the Postgres-specific source code yesterday. It
> doesn't look like it's doing anything strange, but I could easily have
> missed something.
>
> One thing you could try doing is to turn on query logging (set
> log_statement = all) and look to see if rubyrep, or some other part of
> your system, is indeed issuing repeated CREATE OR REPLACE FUNCTION
> commands.
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2012-05-23 21:33 Tom Lane <tgl@sss.pgh.pa.us>
parent: Vincent Dautremont <vincent@searidgetech.com>
0 siblings, 1 reply; 42+ messages in thread
From: Tom Lane @ 2012-05-23 21:33 UTC (permalink / raw)
To: Vincent Dautremont <vincent@searidgetech.com>; +Cc: pgsql-admin
Vincent Dautremont <vincent@searidgetech.com> writes:
> you were right,
> I do see those CREATE OR REPLACE FUNCTION a bit more than 1 per second
> (approx. 12 times for 10 seconds)
Hah. Complain to the rubyrep people. It's most likely just a thinko
about where they should issue that command. If they actually are
changing the function text from one issuance to the next, they would be
well advised to think of a better way to deal with whatever they're
doing that for; it's going to be quite inefficient even without
considering the effects of this leak.
> I don't know a lot about the internal of rubyrep, but do you think this is
> not a normal behaviour from a postgresql server point of view ?
It's not. We have plugged that leak, I think, as of 9.1; but the fact
that it took us this long to notice the leak shows that constant
replacement of a function is not a common usage. All the server's
internal caching related to functions is designed around the assumption
that functions aren't redefined too often.
If you can't get the rubyrep people to fix their code, updating to PG
9.1 is a possible workaround.
regards, tom lane
^ permalink raw reply [nested|flat] 42+ messages in thread
* Re: out of memory error
@ 2012-05-23 21:46 Vincent Dautremont <vincent@searidgetech.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 42+ messages in thread
From: Vincent Dautremont @ 2012-05-23 21:46 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-admin
Well,
Thank you very much for your help, it's greatly appreciated.
At least I can now pinpoint the problem and search for a solution or
another reason to upgrade to 9.1 !
Regards,
Vincent.
On Wed, May 23, 2012 at 5:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Vincent Dautremont <vincent@searidgetech.com> writes:
> > you were right,
> > I do see those CREATE OR REPLACE FUNCTION a bit more than 1 per second
> > (approx. 12 times for 10 seconds)
>
> Hah. Complain to the rubyrep people. It's most likely just a thinko
> about where they should issue that command. If they actually are
> changing the function text from one issuance to the next, they would be
> well advised to think of a better way to deal with whatever they're
> doing that for; it's going to be quite inefficient even without
> considering the effects of this leak.
>
> > I don't know a lot about the internal of rubyrep, but do you think this
> is
> > not a normal behaviour from a postgresql server point of view ?
>
> It's not. We have plugged that leak, I think, as of 9.1; but the fact
> that it took us this long to notice the leak shows that constant
> replacement of a function is not a common usage. All the server's
> internal caching related to functions is designed around the assumption
> that functions aren't redefined too often.
>
> If you can't get the rubyrep people to fix their code, updating to PG
> 9.1 is a possible workaround.
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 42+ messages in thread
end of thread, other threads:[~2012-05-23 21:46 UTC | newest]
Thread overview: 42+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2004-06-08 00:01 out of memory error Adi Alurkar <adi@sf.net>
2004-06-08 00:36 Re: out of memory error Jie Liang <jie@stbernard.com>
2004-06-08 17:28 Re: out of memory error Naomi Walker <nwalke@eldocomp.com>
2004-06-11 01:14 out of memory error Mark Striebeck <mstriebeck@vasoftware.com>
2004-06-11 08:02 ` Richard Huxton <dev@archonet.com>
2004-06-11 11:48 ` Martin Marques <martin@bugs.unl.edu.ar>
2004-06-15 20:24 Out of memory error ow <oneway_111@yahoo.com>
2004-06-16 01:39 ` Re: Out of memory error Tom Lane <tgl@sss.pgh.pa.us>
2005-03-26 04:07 out of memory error pginfo <pginfo@t1.unisoftbg.com>
2005-03-26 10:49 ` pginfo <pginfo@t1.unisoftbg.com>
2006-06-23 17:05 Out of memory error Abu Mushayeed <amushayeed@hotmail.com>
2006-06-23 17:18 ` Re: Out of memory error Tom Lane <tgl@sss.pgh.pa.us>
2010-08-05 13:01 out of memory error Silvio Brandani <silvio.brandani@tech.sdb.it>
2010-08-05 13:22 ` Victor Hugo <vh.clemente@gmail.com>
2010-08-05 14:10 ` Silvio Brandani <silvio.brandani@tech.sdb.it>
2010-08-05 16:13 ` Scott Marlowe <scott.marlowe@gmail.com>
2010-08-05 14:03 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
2010-08-05 14:15 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-08-05 14:29 ` Silvio Brandani <silvio.brandani@tech.sdb.it>
2010-08-05 15:18 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-08-05 17:39 ` Bob Lunney <bob_lunney@yahoo.com>
2010-08-06 08:13 ` Silvio Brandani <silvio.brandani@tech.sdb.it>
2010-08-06 11:56 ` Silvio Brandani <silvio.brandani@tech.sdb.it>
2010-08-06 15:43 ` Alvaro Herrera <alvherre@commandprompt.com>
2010-09-02 12:50 ` Silvio Brandani <silvio.brandani@tech.sdb.it>
2010-09-02 13:37 ` Silvio Brandani <silvio.brandani@tech.sdb.it>
2010-09-02 14:27 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-09-02 15:05 ` Silvio Brandani <silvio.brandani@tech.sdb.it>
2010-09-02 15:09 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-09-03 07:33 ` Silvio Brandani <silvio.brandani@tech.sdb.it>
2010-09-03 08:15 ` Silvio Brandani <silvio.brandani@tech.sdb.it>
2012-05-22 16:44 out of memory error Vincent Dautremont <vincent@searidgetech.com>
2012-05-22 17:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-05-22 18:04 ` Vincent Dautremont <vincent@searidgetech.com>
2012-05-22 18:30 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-05-22 19:46 ` Vincent Dautremont <vincent@searidgetech.com>
2012-05-22 20:04 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-05-23 14:06 ` Vincent Dautremont <vincent@searidgetech.com>
2012-05-23 15:26 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-05-23 21:22 ` Vincent Dautremont <vincent@searidgetech.com>
2012-05-23 21:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2012-05-23 21:46 ` Vincent Dautremont <vincent@searidgetech.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox