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.
+1 for tracking wait events not only for backends
Ildus, could you do following?
1) Extract LWLocks refactoring into separate patch.
2) Make a patch with storing current wait event information in PGPROC.
