On Thu, Aug 6, 2015 at 3:31 PM, Ildus Kurbangaliev <
i.kurbangaliev@postgrespro.ru> wrote:
>
> On 08/05/2015 09:33 PM, Robert Haas wrote:
>>
>>
>> You're missing the point. Those multi-byte fields have additional
>> synchronization requirements, as I explained in some detail in my
>> previous email. You can't just wave that away.
>
> I see that now. Thank you for the point.
>
> I've looked deeper and I found PgBackendStatus to be not a suitable
> place for keeping information about low level waits. Really, PgBackendStatus
> is used to track high level information about backend. This is why auxiliary
> processes don't have PgBackendStatus, because they don't have such information
> to expose. But when we come to the low level wait events then auxiliary
> processes are as useful for monitoring as backends are. WAL writer,
> checkpointer, bgwriter etc are using LWLocks as well. This is certainly unclear
> why they can't be monitored.
>
I think the chances of background processes stuck in LWLock is quite less
as compare to backends as they do the activities periodically. As an example
WALWriter will take WALWriteLock to write the WAL, but actually there will never
be any much contention for WALWriter. In synchronous_commit = on, the
backends themselves write the WAL so WALWriter won't do much in that
case and for synchronous_commit = off, backends won't write the WAL so
WALWriter won't face any contention unless some buffers have to be written
by bgwriter or checkpoint for which WAL is not flushed which I don't think
would lead to any contention.
I am not denying from the fact that there could be some contention in rare
scenarios for background processes, but I think tracking them is not as
important as tracking the LWLocks for backends.
Also as we are planning to track the wait_event information in pg_stat_activity
along with other backends information, it will not make sense to include
information about backend processes in this variable as pg_stat_activity
just displays information of backend processes.
