Re: New statistics for tuning WAL buffer size - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: New statistics for tuning WAL buffer size
Date
Msg-id 3fd9340e-e46e-fb1c-009d-affb0b2b24ef@oss.nttdata.com
Whole thread Raw
In response to Re: New statistics for tuning WAL buffer size  (Masahiro Ikeda <ikedamsh@oss.nttdata.com>)
Responses RE: New statistics for tuning WAL buffer size
List pgsql-hackers

On 2020/09/02 18:56, Masahiro Ikeda wrote:
>> +/* ----------
>> + * Backend types
>> + * ----------
>>
>> You seem to forget to add "*/" into the above comment.
>> This issue could cause the following compiler warning.
>> ../../src/include/pgstat.h:761:1: warning: '/*' within block comment [-Wcomment]
> 
> Thanks for the comment. I fixed.

Thanks for the fix! But why are those comments necessary?


> 
>> The contents of pg_stat_walwrites are reset when the server
>> is restarted. Isn't this problematic? IMO since pg_stat_walwrites
>> is a collected statistics view, basically its contents should be
>> kept even in the case of server restart.
> 
> I agree your opinion.
> I modified to use the statistics collector and persist the wal statistics.
> 
> 
> I changed the view name from pg_stat_walwrites to pg_stat_walwriter.
> I think it is better to match naming scheme with other views like pg_stat_bgwriter,
> which is for bgwriter statistics but it has the statistics related to backend.

I prefer the view name pg_stat_walwriter for the consistency with
other view names. But we also have pg_stat_wal_receiver. Which
makes me think that maybe pg_stat_wal_writer is better for
the consistency. Thought? IMO either of them works for me.
I'd like to hear more opinons about this.


> 
> The pg_stat_walwriter is not security restricted now, so ordinary users can access it.
> I has the same security level as pg_stat_archiver.If you have any comments, please let me know.

+       <structfield>dirty_writes</structfield> <type>bigint</type>

I guess that the column name "dirty_writes" derived from
the DTrace probe name. Isn't this name confusing? We should
rename it to "wal_buffers_full" or something?


+/* ----------
+ * PgStat_MsgWalWriter            Sent by the walwriter to update statistics.

This comment seems not accurate because backends also send it.

+/*
+ * WAL writes statistics counter is updated in XLogWrite function
+ */
+extern PgStat_MsgWalWriter WalWriterStats;

This comment seems not right because the counter is not updated in XLogWrite().

+-- There will surely and maximum one record
+select count(*) = 1 as ok from pg_stat_walwriter;

What about changing this comment to "There must be only one record"?

+                    WalWriterStats.m_xlog_dirty_writes++;
                      LWLockRelease(WALWriteLock);

Since WalWriterStats.m_xlog_dirty_writes doesn't need to be protected
with WALWriteLock, isn't it better to increment that after releasing the lock?

+CREATE VIEW pg_stat_walwriter AS
+    SELECT
+        pg_stat_get_xlog_dirty_writes() AS dirty_writes,
+        pg_stat_get_walwriter_stat_reset_time() AS stats_reset;
+
  CREATE VIEW pg_stat_progress_vacuum AS

In system_views.sql, the definition of pg_stat_walwriter should be
placed just after that of pg_stat_bgwriter not pg_stat_progress_analyze.

      }
-
      /*
       * We found an existing collector stats file. Read it and put all the

You seem to accidentally have removed the empty line here.

-                 errhint("Target must be \"archiver\" or \"bgwriter\".")));
+                 errhint("Target must be \"archiver\" or \"bgwriter\" or \"walwriter\".")));

There are two "or" in the message, but the former should be replaced with ","?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Re: Parallel copy
Next
From: Peter Smith
Date:
Subject: Re: extension patch of CREATE OR REPLACE TRIGGER