Re: transaction delays to apply
От | Nickolay |
---|---|
Тема | Re: transaction delays to apply |
Дата | |
Msg-id | 4A83FF07.9030805@zhukcity.ru обсуждение исходный текст |
Ответ на | Re: transaction delays to apply (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
Tom Lane wrote: > Nickolay <nitro@zhukcity.ru> 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.
В списке pgsql-performance по дате отправления: