Re: pg_stat_io for the startup process

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

In response to

Responses

Browse pgsql-hackers by date

  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)