Tom Lane wrote:
Nickolay <nitro@xxxxxxxxxxx> writes:
BUT it seems that rarely this transaction is being delayed to apply and
log entry is being inserted in wrong order:
ID timestamp
1 2009-08-08 00:00:00.111
2 2009-08-08 00:00:30.311
3 2009-08-08 00:00:00.211
Yep, that's right - sometimes for 30 seconds or even more.
You haven't provided enough information to let anyone guess at the
problem. Have you checked to see if one of the processes is blocking
on a lock, or perhaps there's a sudden spike in system load, or what?
Watching pg_stat_activity, pg_locks, and/or "vmstat 1" output during
one of these events might help narrow down what's happening.
regards, tom lane
The problem is that such thing happens very rare, and NOT at full load.
I can't monitor the system all the time. Is there any way to investigate
the situation by any of pgsql logs or enable something like full debug?
I do have a row-level lock (SELECT...FOR UPDATE) on another table during
this transaction, but one row are handled by not more than 2 processes
at once and it should be very quick (SELECT, parse data and UPDATE).
Thank you very much for you help!
Best regards, Nick.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
