From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | andres(at)anarazel(dot)de |
Cc: | m(dot)melihmutlu(at)gmail(dot)com, robertmhaas(at)gmail(dot)com, masao(dot)fujii(at)oss(dot)nttdata(dot)com, pgsql-hackers(at)postgresql(dot)org, melanieplageman(at)gmail(dot)com |
Subject: | Re: pg_stat_io for the startup process |
Date: | 2023-05-22 04:36:42 |
Message-ID: | 20230522.133642.59055694182642172.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Sun, 21 May 2023 15:14:23 -0700, Andres Freund <andres(at)anarazel(dot)de> wrote in
> Hi,
>
> I don't really feel confident we're going to get the timeout approach solid
> enough for something going into the tree around beta 1.
>
> How about this, imo a lot simpler, approach: We flush stats whenever replaying
> a XLOG_RUNNING_XACTS record. Unless the primary is idle, it will log those at
> a regular interval. If the primary is idle, we don't need to flush stats in
> the startup process, because we'll not have done any io.
>
> We only log XLOG_RUNNING_XACTS when wal_level >= replica, so stats wouldn't
> get regularly flushed if wal_level = minimal - but in that case the stats are
> also not accessible, so that's not a problem.
I concur with the three aspects, interval regularity, reliability and
about the case of the minimal wal_level. While I can't confidently
claim it is the best, its simplicilty gives us a solid reason to
proceed with it. If necessary, we can switch to alternative timing
sources in the future without causing major disruptions for users, I
believe.
> It's not the prettiest solution, but I think the simplicity is worth a lot.
>
> Greetings,
+1.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Kirk Wolak | 2023-05-22 05:19:21 | Re: Adding SHOW CREATE TABLE |
Previous Message | Thomas Munro | 2023-05-22 03:38:44 | Re: LLVM 16 (opaque pointers) |