Re: RFC: replace pg_stat_activity.waiting with something more descriptive - Mailing list pgsql-hackers
| From | Vladimir Borodin |
|---|---|
| Subject | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
| Date | |
| Msg-id | 9A99C2A7-1760-419F-BDC9-A2CF99ECD694@simply.name Whole thread Raw |
| In response to | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Amit Kapila <amit.kapila16@gmail.com>) |
| List | pgsql-hackers |
12 сент. 2015 г., в 14:05, Amit Kapila <amit.kapila16@gmail.com> написал(а):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 lessas compare to backends as they do the activities periodically. As an exampleWALWriter will take WALWriteLock to write the WAL, but actually there will neverbe any much contention for WALWriter. In synchronous_commit = on, thebackends themselves write the WAL so WALWriter won't do much in thatcase and for synchronous_commit = off, backends won't write the WAL soWALWriter won't face any contention unless some buffers have to be writtenby bgwriter or checkpoint for which WAL is not flushed which I don't thinkwould lead to any contention.
WALWriter is not a good example, IMHO. And monitoring LWLocks is not the only thing that waits monitoring brings to us. Here [0] is an example when understanding of what is happening inside the startup process took some long time and led to GDB usage. With waits monitoring I could do a couple of SELECTs and use oid2name to understand the reason of a problem.
Also we should consider that PostgreSQL has a good infrastructure to parallelize many auxilary processes. Can we be sure that we will always have exactly one wal writer process? Perhaps, some time in the future we would need several of them and there would be contention for WALWriteLock between them. Perhaps, wal writer is not a good example here too, but having multiple checkpointer or bgwriter processes on the near future seems very likely, no?
I am not denying from the fact that there could be some contention in rarescenarios for background processes, but I think tracking them is not asimportant as tracking the LWLocks for backends.Also as we are planning to track the wait_event information in pg_stat_activityalong with other backends information, it will not make sense to includeinformation about backend processes in this variable as pg_stat_activityjust displays information of backend processes.
pgsql-hackers by date: