On 08/05/2015 09:33 PM, Robert Haas wrote:
> On Wed, Aug 5, 2015 at 1:10 PM, Ildus Kurbangaliev
> <i.kurbangaliev@postgrespro.ru> wrote:
>> About `memcpy`, PgBackendStatus struct already have a bunch of multi-byte
>> variables, so it will be
>> not consistent anyway if somebody will want to copy it in that way. On the
>> other hand two bytes in this case
>> give less overhead because we can avoid the offset calculations. And as I've
>> mentioned before the class
>> of wait will be useful when monitoring of waits will be extended.
> 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.
This is why I think we shoudn't place wait event into PgBackendStatus. It
could be placed into PGPROC or even separate data structure with different
concurrency model which would be most suitable for monitoring.
--
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
