Re: transaction delays to apply

От: Nickolay
Тема: Re: transaction delays to apply
Дата: ,
Msg-id: 4A83FF07.9030805@zhukcity.ru
(см: обсуждение, исходный текст)
Ответ на: Re: transaction delays to apply  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

transaction delays to apply  (Nickolay, )
 Re: transaction delays to apply  (Pierre Frédéric Caillaud<>, )
 Re: transaction delays to apply  (Tom Lane, )
  Re: transaction delays to apply  (Nickolay, )
  Re: transaction delays to apply  (Nickolay, )

Tom Lane wrote:
> Nickolay <> 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 по дате сообщения:

От: Richard Huxton
Дата:
Сообщение: Re: Under the hood of views
От: Rstat
Дата:
Сообщение: Less expensive proprietary or Open source ETL tools