Обсуждение: Re: shared-memory based stats collector - v70

At Thu, 7 Apr 2022 16:37:51 -0700, Andres Freund <andres@anarazel.de> wrote in 
> Hi,
> 
> On 2022-04-07 00:28:45 -0700, Andres Freund wrote:
> > I've gotten through the main commits (and then a fix for the apparently
> > inevitable bug that's immediately highlighted by the buildfarm), and the first
> > test. I'll call it a night now, and work on the other tests & docs tomorrow.
> 
> I've gotten through the tests now. There's one known, not yet addressed, issue
> with the stats isolation test, see [1].
> 
> 
> Working on the docs. Found a few things worth raising:
> 
> 1)
> Existing text:
>    When the server shuts down cleanly, a permanent copy of the statistics
>    data is stored in the <filename>pg_stat</filename> subdirectory, so that
>    statistics can be retained across server restarts.  When recovery is
>    performed at server start (e.g., after immediate shutdown, server crash,
>    and point-in-time recovery), all statistics counters are reset.
> 
> The existing docs patch hadn't updated yet. My current edit is
> 
>    When the server shuts down cleanly, a permanent copy of the statistics
>    data is stored in the <filename>pg_stat</filename> subdirectory, so that
>    statistics can be retained across server restarts.  When crash recovery is
>    performed at server start (e.g., after immediate shutdown, server crash,
>    and point-in-time recovery, but not when starting a standby that was shut
>    down normally), all statistics counters are reset.
> 
> but I'm not sure the parenthetical is easy enough to understand?

I can read it. But I'm not sure that the difference is obvious for
average users between "starting a standby from a basebackup" and
"starting a standby after a normal shutdown"..

Other than that, it might be easier to read if the additional part
were moved out to the end of the paragraph, prefixing with "Note:
". For example,

...
statistics can be retained across server restarts.  When crash recovery is
performed at server start (e.g., after immediate shutdown, server crash,
and point-in-time recovery), all statistics counters are reset. Note that
crash recovery is not performed when starting a standby that was shut
down normally then all counters are retained.

> 2)
> The edit is not a problem, but it's hard to understand what the existing
> paragraph actually means?
> 
> diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
> index 3247e056663..8bfb584b752 100644
> --- a/doc/src/sgml/high-availability.sgml
> +++ b/doc/src/sgml/high-availability.sgml
> @@ -2222,17 +2222,17 @@ HINT:  You can then restart the server after making the necessary configuration
> ...
>     <para>
> -    The statistics collector is active during recovery. All scans, reads, blocks,
> +    The cumulative statistics system is active during recovery. All scans, reads, blocks,
>      index usage, etc., will be recorded normally on the standby. Replayed
>      actions will not duplicate their effects on primary, so replaying an
>      insert will not increment the Inserts column of pg_stat_user_tables.
>      The stats file is deleted at the start of recovery, so stats from primary
>      and standby will differ; this is considered a feature, not a bug.
>     </para>
> 
>     <para>

Agreed partially. It's too detailed.  It might not need to mention WAL
replay.

> I'll just commit the necessary bit, but we really ought to rephrase this.
> 
> 
> 
> 
> Greetings,
> 
> Andres Freund
> 
> [1] https://www.postgresql.org/message-id/20220407165709.jgdkrzqlkcwue6ko%40alap3.anarazel.de

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Hi,

On 2022-04-08 11:10:14 +0900, Kyotaro Horiguchi wrote:
> At Thu, 7 Apr 2022 16:37:51 -0700, Andres Freund <andres@anarazel.de> wrote in 
> > Hi,
> > 
> > On 2022-04-07 00:28:45 -0700, Andres Freund wrote:
> > > I've gotten through the main commits (and then a fix for the apparently
> > > inevitable bug that's immediately highlighted by the buildfarm), and the first
> > > test. I'll call it a night now, and work on the other tests & docs tomorrow.
> > 
> > I've gotten through the tests now. There's one known, not yet addressed, issue
> > with the stats isolation test, see [1].
> > 
> > 
> > Working on the docs. Found a few things worth raising:
> > 
> > 1)
> > Existing text:
> >    When the server shuts down cleanly, a permanent copy of the statistics
> >    data is stored in the <filename>pg_stat</filename> subdirectory, so that
> >    statistics can be retained across server restarts.  When recovery is
> >    performed at server start (e.g., after immediate shutdown, server crash,
> >    and point-in-time recovery), all statistics counters are reset.
> > 
> > The existing docs patch hadn't updated yet. My current edit is
> > 
> >    When the server shuts down cleanly, a permanent copy of the statistics
> >    data is stored in the <filename>pg_stat</filename> subdirectory, so that
> >    statistics can be retained across server restarts.  When crash recovery is
> >    performed at server start (e.g., after immediate shutdown, server crash,
> >    and point-in-time recovery, but not when starting a standby that was shut
> >    down normally), all statistics counters are reset.
> > 
> > but I'm not sure the parenthetical is easy enough to understand?
> 
> I can read it. But I'm not sure that the difference is obvious for
> average users between "starting a standby from a basebackup" and
> "starting a standby after a normal shutdown"..

Yea, that's what I was concerned about. How about:

  <para>
   Cumulative statistics are collected in shared memory. Every
   <productname>PostgreSQL</productname> process collects statistics locally
   then updates the shared data at appropriate intervals.  When a server,
   including a physical replica, shuts down cleanly, a permanent copy of the
   statistics data is stored in the <filename>pg_stat</filename> subdirectory,
   so that statistics can be retained across server restarts.  In contrast,
   when starting from an unclean shutdown (e.g., after an immediate shutdown,
   a server crash, starting from a base backup, and point-in-time recovery),
   all statistics counters are reset.
  </para>


> Other than that, it might be easier to read if the additional part
> were moved out to the end of the paragraph, prefixing with "Note:
> ". For example,
> 
> ...
> statistics can be retained across server restarts.  When crash recovery is
> performed at server start (e.g., after immediate shutdown, server crash,
> and point-in-time recovery), all statistics counters are reset. Note that
> crash recovery is not performed when starting a standby that was shut
> down normally then all counters are retained.

I think I like my version above a bit better?


> > 2)
> > The edit is not a problem, but it's hard to understand what the existing
> > paragraph actually means?
> > 
> > diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
> > index 3247e056663..8bfb584b752 100644
> > --- a/doc/src/sgml/high-availability.sgml
> > +++ b/doc/src/sgml/high-availability.sgml
> > @@ -2222,17 +2222,17 @@ HINT:  You can then restart the server after making the necessary configuration
> > ...
> >     <para>
> > -    The statistics collector is active during recovery. All scans, reads, blocks,
> > +    The cumulative statistics system is active during recovery. All scans, reads, blocks,
> >      index usage, etc., will be recorded normally on the standby. Replayed
> >      actions will not duplicate their effects on primary, so replaying an
> >      insert will not increment the Inserts column of pg_stat_user_tables.
> >      The stats file is deleted at the start of recovery, so stats from primary
> >      and standby will differ; this is considered a feature, not a bug.
> >     </para>
> > 
> >     <para>
> 
> Agreed partially. It's too detailed.  It might not need to mention WAL
> replay.

My concern is more that it seems halfway nonsensical. "Replayed actions will
not duplicate their effects on primary" - I can guess what that means, but not
more. There's no "Inserts" column of pg_stat_user_tables.


   <para>
    The cumulative statistics system is active during recovery. All scans,
    reads, blocks, index usage, etc., will be recorded normally on the
    standby. However, WAL replay will not increment relation and database
    specific counters. I.e. replay will not increment pg_stat_all_tables
    columns (like n_tup_ins), nor will reads or writes performed by the
    startup process be tracked in the pg_statio views, nor will associated
    pg_stat_database columns be incremented.
   </para>



Greetings,

Andres Freund

Hi,

On 2022-04-07 20:51:10 -0700, David G. Johnston wrote:
> On Thu, Apr 7, 2022 at 7:10 PM Kyotaro Horiguchi <horikyota.ntt@gmail.com>
> wrote:
> > I can read it. But I'm not sure that the difference is obvious for
> > average users between "starting a standby from a basebackup" and
> > "starting a standby after a normal shutdown"..
> >
> > Other than that, it might be easier to read if the additional part
> > were moved out to the end of the paragraph, prefixing with "Note:
> > ". For example,
> >
> > ...
> > statistics can be retained across server restarts.  When crash recovery is
> > performed at server start (e.g., after immediate shutdown, server crash,
> > and point-in-time recovery), all statistics counters are reset. Note that
> > crash recovery is not performed when starting a standby that was shut
> > down normally then all counters are retained.
> >
> >
> Maybe:
> When the server shuts down cleanly a permanent copy of the statistics data
> is stored in the <filename>pg_stat</filename> subdirectory so that
> statistics can be retained across server restarts.  However, if crash
> recovery is performed (i.e., after immediate shutdown, server crash, or
> point-in-time recovery), all statistics counters are reset.  For any
> standby server, the initial startup to get the cluster initialized is a
> point-in-time crash recovery startup. For all subsequent startups it
> behaves like any other server.  For a hot standby server, statistics are
> retained during a failover promotion.
> 
> I'm pretty sure i.e., is correct since those three situations are not
> examples but rather the complete set.

I don't think the "initial startup ..." bit is quite correct. A standby can be
created for a shut down server, and IIRC there's some differences in how PITR
is handled too.


> Is crash recovery ever performed other than at server start?  If so I
> choose to remove the redundancy.

No.


> I feel like some of this detail about standby servers is/should be covered
> elsewhere and we are at least missing a cross-reference chance even if we
> leave the material coverage as-is.

I didn't find anything good to reference...


> > 2)
> > > The edit is not a problem, but it's hard to understand what the existing
> > > paragraph actually means?
> > >
> > > diff --git a/doc/src/sgml/high-availability.sgml
> > b/doc/src/sgml/high-availability.sgml
> > > index 3247e056663..8bfb584b752 100644
> > > --- a/doc/src/sgml/high-availability.sgml
> > > +++ b/doc/src/sgml/high-availability.sgml
> > > @@ -2222,17 +2222,17 @@ HINT:  You can then restart the server after
> > making the necessary configuration
> > > ...
> > >     <para>
> > > -    The statistics collector is active during recovery. All scans,
> > reads, blocks,
> > > +    The cumulative statistics system is active during recovery. All
> > scans, reads, blocks,
> > >      index usage, etc., will be recorded normally on the standby.
> > Replayed
> > >      actions will not duplicate their effects on primary, so replaying an
> > >      insert will not increment the Inserts column of pg_stat_user_tables.
> > >      The stats file is deleted at the start of recovery, so stats from
> > primary
> > >      and standby will differ; this is considered a feature, not a bug.
> > >     </para>
> > >
> > >     <para>
> >
> > Agreed partially. It's too detailed.  It might not need to mention WAL
> > replay.
> >
> >
> The insert example seems like a poor one...IIUC cumulative statistics are
> not WAL logged and while in recovery INSERT is prohibited, so how would
> replaying the insert in the WAL result in a duplicated effect on
> pg_stat_user_tables.inserts?

I agree, the sentence doesn't make much sense.

It doesn't really matter that stats aren't WAL logged, one could infer them
from the WAL at a decent level of accuracy. However, we can't actually
associate those actions to relations, we just know the relfilenode... And the
startup process can't read the catalog to figure the mapping out.


> I also have no idea what, in the fragment, "Replayed actions will not
> duplicate their effects on primary...", what "on primary" is supposed to
> mean.

I think it's trying to say "will not duplicate the effect on
pg_stat_user_tables they had on the primary".


> I would like to write the following but I don't believe it is sufficiently
> true:
> 
> "The cumulative statistics system records only the locally generated
> activity of the cluster, including while in recovery.  Activity happening
> only due to the replay of WAL is not considered local."
> 
> But to apply the WAL we have to fetch blocks from the local filesystem and
> write them back out.  That is local activity happening due to the replay of
> WAL which sounds like it is and should be reported ("All...blocks...", and
> the example given being logical DDL oriented).

That's not true today - the startup processes reads / writes aren't reflected
in pg_statio, pg_stat_database or whatnot.


> I cannot think of a better paragraph at the moment, the minimal change is
> good, and the detail it contains presently seems like the right amount, if
> indeed my interpretation of it is correct (i.e., the standby records
> physical stats, not logical ones).  It still has wording issues around "on
> primary" and maybe a better example choice than a
> disallowed-in-recovery-anyway insert.

What do you think about my suggested paragraphs in
https://postgr.es/m/20220408035921.xlmjrv7wdmk3xm7k%40alap3.anarazel.de ?

Greetings,

Andres Freund

Hi,

On 2022-04-07 20:59:21 -0700, Andres Freund wrote:
> 
>   <para>
>    Cumulative statistics are collected in shared memory. Every
>    <productname>PostgreSQL</productname> process collects statistics locally
>    then updates the shared data at appropriate intervals.  When a server,
>    including a physical replica, shuts down cleanly, a permanent copy of the
>    statistics data is stored in the <filename>pg_stat</filename> subdirectory,
>    so that statistics can be retained across server restarts.  In contrast,
>    when starting from an unclean shutdown (e.g., after an immediate shutdown,
>    a server crash, starting from a base backup, and point-in-time recovery),
>    all statistics counters are reset.
>   </para>
> ...
>    <para>
>     The cumulative statistics system is active during recovery. All scans,
>     reads, blocks, index usage, etc., will be recorded normally on the
>     standby. However, WAL replay will not increment relation and database
>     specific counters. I.e. replay will not increment pg_stat_all_tables
>     columns (like n_tup_ins), nor will reads or writes performed by the
>     startup process be tracked in the pg_statio views, nor will associated
>     pg_stat_database columns be incremented.
>    </para>

I went with these for now. My guess is that there's further improvements in
them, and in surrounding areas...


With that, I'll close this CF entry. It's been a while.

Greetings,

Andres Freund

At Thu, 7 Apr 2022 20:59:21 -0700, Andres Freund <andres@anarazel.de> wrote in 
> Hi,
> 
> On 2022-04-08 11:10:14 +0900, Kyotaro Horiguchi wrote:
> > I can read it. But I'm not sure that the difference is obvious for
> > average users between "starting a standby from a basebackup" and
> > "starting a standby after a normal shutdown"..
> 
> Yea, that's what I was concerned about. How about:
> 
>   <para>
>    Cumulative statistics are collected in shared memory. Every
>    <productname>PostgreSQL</productname> process collects statistics locally
>    then updates the shared data at appropriate intervals.  When a server,
>    including a physical replica, shuts down cleanly, a permanent copy of the
>    statistics data is stored in the <filename>pg_stat</filename> subdirectory,
>    so that statistics can be retained across server restarts.  In contrast,
>    when starting from an unclean shutdown (e.g., after an immediate shutdown,
>    a server crash, starting from a base backup, and point-in-time recovery),
>    all statistics counters are reset.
>   </para>

Looks perfect generally, and especially in regard to the concern.

> I think I like my version above a bit better?

Quite a bit.  It didn't answer for the concern.

> > > 2)
> > > The edit is not a problem, but it's hard to understand what the existing
> > > paragraph actually means?
> > > 
> > > diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
> > > index 3247e056663..8bfb584b752 100644
> > > --- a/doc/src/sgml/high-availability.sgml
> > > +++ b/doc/src/sgml/high-availability.sgml
> > > @@ -2222,17 +2222,17 @@ HINT:  You can then restart the server after making the necessary configuration
> > > ...
> > >     <para>
> > > -    The statistics collector is active during recovery. All scans, reads, blocks,
> > > +    The cumulative statistics system is active during recovery. All scans, reads, blocks,
> > >      index usage, etc., will be recorded normally on the standby. Replayed
> > >      actions will not duplicate their effects on primary, so replaying an
> > >      insert will not increment the Inserts column of pg_stat_user_tables.
> > >      The stats file is deleted at the start of recovery, so stats from primary
> > >      and standby will differ; this is considered a feature, not a bug.
> > >     </para>
> > > 
> > >     <para>
> > 
> > Agreed partially. It's too detailed.  It might not need to mention WAL
> > replay.
> 
> My concern is more that it seems halfway nonsensical. "Replayed actions will
> not duplicate their effects on primary" - I can guess what that means, but not
> more. There's no "Inserts" column of pg_stat_user_tables.
> 
> 
>    <para>
>     The cumulative statistics system is active during recovery. All scans,
>     reads, blocks, index usage, etc., will be recorded normally on the
>     standby. However, WAL replay will not increment relation and database
>     specific counters. I.e. replay will not increment pg_stat_all_tables
>     columns (like n_tup_ins), nor will reads or writes performed by the
>     startup process be tracked in the pg_statio views, nor will associated
>     pg_stat_database columns be incremented.
>    </para>

Looks clearer since it mention user-facing interfaces with concrete
example columns.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Hi,

On 2022-04-07 21:39:55 -0700, David G. Johnston wrote:
> On Thu, Apr 7, 2022 at 8:59 PM Andres Freund <andres@anarazel.de> wrote:
> 
> >
> >   <para>
> >    Cumulative statistics are collected in shared memory. Every
> >    <productname>PostgreSQL</productname> process collects statistics
> > locally
> >    then updates the shared data at appropriate intervals.  When a server,
> >    including a physical replica, shuts down cleanly, a permanent copy of
> > the
> >    statistics data is stored in the <filename>pg_stat</filename>
> > subdirectory,
> >    so that statistics can be retained across server restarts.  In contrast,
> >    when starting from an unclean shutdown (e.g., after an immediate
> > shutdown,
> >    a server crash, starting from a base backup, and point-in-time
> > recovery),
> >    all statistics counters are reset.
> >   </para>
> >
> 
> I like this.  My comment regarding using "i.e.," here stands though.

Argh. I'd used in e.g., but not i.e..


> >
> >    <para>
> >     The cumulative statistics system is active during recovery. All scans,
> >     reads, blocks, index usage, etc., will be recorded normally on the
> >     standby. However, WAL replay will not increment relation and database
> >     specific counters. I.e. replay will not increment pg_stat_all_tables
> >     columns (like n_tup_ins), nor will reads or writes performed by the
> >     startup process be tracked in the pg_statio views, nor will associated
> >     pg_stat_database columns be incremented.
> >    </para>
> >
> >
> I like this too.  The second part with three nors is a bit rough.  Maybe:

Agreed. I tried to come up with a smoother formulation, but didn't (perhaps
because I was a tad tired).


> ... specific counters.  In particular, replay will not increment
> pg_stat_database or pg_stat_all_tables columns, and the startup process
> will not report reads and writes for the pg_statio views.
> 
> It would helpful to give at least one specific example of what is being
> recorded normally, especially since we give three of what is not.

The second sentence is a set of examples - or do you mean examples for what
actions by the startup process are counted?

Greetings,

Andres Freund