On 17/12/14 16:14, Alessandro Ipe wrote:
> 2014-12-15 17:54:07 GMT LOG: server process (PID 21897) was terminated
> by signal 9: Killed
since it was killed by SIGKILL, maybe it's the kernel's OOM killer?
Torsten
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To m
Alessandro Ipe writes:
> My dtrigger definition is
> CREATE TRIGGER msg_trigger BEFORE INSERT ON msg FOR EACH ROW EXECUTE
> PROCEDURE msg_function();
> so it seems that it is a BEFORE trigger.
Hm, no AFTER triggers anywhere? Are there foreign keys, perhaps?
regards, tom
Hi,
My dtrigger definition is
CREATE TRIGGER msg_trigger BEFORE INSERT ON msg FOR EACH ROW EXECUTE PROCEDURE
msg_function();
so it seems that it is a BEFORE trigger.
To be totally honest, I have "really" limited knownledge in SQL and postgresql
and all these were gathered from recipes found on
Hi Torsten,
Thanks for your answer.
I have modified
(SELECT * FROM upsert)
to
(SELECT * FROM upsert WHERE slot=to_timestamp('201212032145', 'MMDDHH24MI')
and MSG=2)
according to your suggestion to reduce the result-set to a single row. However,
the INSERT process is still consuming the sam
Torsten Zuehlsdorff writes:
> How many rows is "(SELECT * FROM upsert)" returning? Without knowing
> more i would guess, that the result-set is very big and that could be
> the reason for the memory usage.
Result sets are not ordinarily accumulated on the server side.
Alessandro didn't show th
Hello Alessandro,
2014-12-15 17:54:07 GMT DETAIL: Failed process was running: WITH upsert
AS (update MSG set
(slot,MSG,HRV,VIS006,VIS008,IR_016,IR_039,WV_062,WV_073,IR_087,IR_097,IR_108,IR_120,IR_134,PRO,EPI,CLM,TAPE)
= (to_timestamp('201212032145',
'MMDDHH24MI'),2,'\xff','\xff','\xff','
Hi,
Software and hardware running postgresql are:
- postgresql92-9.2.3-1.1.1.x86_64
- openSuSE 12.3 x64_86
- 16 GB of RAM
- 2 GB of swap
- 8-core Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz
- ext4 filesystem hold on a hardware Dell PERC H710 RAID10 with 4x4TB SATA HDs.
- 2 GB of RAM are reserved for
