At Fri, 6 Dec 2019 11:22:14 +0300, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote in > > > On 06.12.2019 4:57, Michael Paquier wrote: > > On Thu, Dec 05, 2019 at 12:23:40PM +0300, Konstantin Knizhnik wrote: > > Please see pgstat.h, close to pgstat_report_wait_start(). > > Sorry, I do not understand what should I look for? > Do you mean this comment: > /* > * Since this is a four-byte field which is always read and > written as > * four-bytes, updates are atomic. > */ > > Yes, I already have noticed that as far as walWritten is 64-bit, its > update is not atomic at 32-bit platforms and so it is possible to see > sometimes incorrect values. > So monotone observe of walWritten can be violated. From my point of > view it is not so critical to enforce update of this fields under lock > or accumulating result in local variable with later write it to > backend status at commit time as Kyotaro proposed. Monitoring of WAL > activity is especially interested for long living transactions and > from my point of view it is much more > important to be able to see up-to-date but may be not always correct > information then do not see any information at all before commit. > Please also take in account the percent of 32-bit Postgres > installations and probability of observing non-atomic update of 64-bit > walWritten field (I think that you will have no chances to see it even > if you will run Postgres for a years).
Still I'm not sure non-atomic write is acceptable, but I agree on the necessity of updating it during a transaction. Couldn't we update shared stats every n bytes (XLOG_BLCKSZ or such) or every command end? I think we should refrain from inserting an instruction within the WALInsertLock section, but I'm not sure which is better between "var += var" within the section and "if (inserted) var += var;" outside. If we can ignore the possitbility of the case where xlogswitch is omitted, the "if (inserted)" is not needed. > But what I mean by "wrongly report backend wait event status" is that > pg_stat_activity may report wait event status for wrong backend. > I.e. if backend is already terminated and its PGPROC entry is reused > by some other backend, than you can see incorrect wait event > information: > backend with such PID actually never sleep on this event. I saw a case where an entry with very old xact_start_timestamp suddenly popped up in pg_stat_activity but I haven't found the cause.. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
