From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | k(dot)knizhnik(at)postgrespro(dot)ru |
Cc: | michael(at)paquier(dot)xyz, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Session WAL activity |
Date: | 2019-12-11 04:26:22 |
Message-ID: | 20191211.132622.1062198697412529527.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Fri, 6 Dec 2019 11:22:14 +0300, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-12-11 05:20:02 | Re: Fetching timeline during recovery |
Previous Message | Amit Kapila | 2019-12-11 03:11:14 | Re: Wrong assert in TransactionGroupUpdateXidStatus |