Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nemVk-0005Dj-2h for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Apr 2022 23:34:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nemVg-0008UX-Rs for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Apr 2022 23:34:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nemVg-0008UO-GQ for pgsql-hackers@lists.postgresql.org; Wed, 13 Apr 2022 23:34:52 +0000 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nemVd-0005nk-O6 for pgsql-hackers@lists.postgresql.org; Wed, 13 Apr 2022 23:34:51 +0000 Received: by mail-ed1-x535.google.com with SMTP id c64so4262546edf.11 for ; Wed, 13 Apr 2022 16:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3JGOLWAuDWdkrH3HW2RqxHFfY7R4ZU21Lrc/h4Qt9/4=; b=d+co2BqxCnb8EhKvuHWNdgCd7aRK3kaZDhIqYen/79h0sxRiFbMj7d5S5zJYiNtWlE HeRokFrqvjMekMJIeNjvvRlVcJP41aBYqJCFJCOCJ/mnSan5at3qQZZoezgo0H6Lo3W+ 2Kfgr2DxmgtOu5c+QRF5F82EoZMYf/ZW/1su3RE04njVYdQDBmsNDt8hSm5tz+fkOLQq t5Kfln1swLQYfI+8hfgm+4zuSS7CEqD8nO50xIjCCxueyu0aSF8mcBxDWAYDo/UlsOrR 5OLyJxXbkCmu7yLgl3syzHQ6r76lfyoK1XkcRYZC+L9MONLnIYcf2WM1vxs0GVGHc6ab ZaJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3JGOLWAuDWdkrH3HW2RqxHFfY7R4ZU21Lrc/h4Qt9/4=; b=vc3OHolZRYSq82lcxSrlMzDiUNKZpk5ZftySaj3M5vtC265O5x/qra5M1T0dac+bWZ RT7qOoFGb6uAtonaODMv2YhRMn3zvzaLYAmmqS231OTosFEfRmiq+47rRdk/6zYbU2LN KDHnNjvrThIhGLh2+vVGtfIhSTxX/pf2Pd20e0gUhY7IBk5p88teKjNzi5hC6LobQu+J x8qRL8QJXwfXP+T1WcMIwc08BSyF/OCLY6VmFHcim2GGpWz++ks7cSskAOycZHd6Mjp+ 5HuHTVC5yyOsk7uAHWil/eaIdvdN12RC+nsqOw4H8tjVqK4lB0vH5MXadVo7cuL0keHY 01lw== X-Gm-Message-State: AOAM531pEF0dK/hwI24rkLQayN1L3malzrOfiyhiqxOoGjp/7diiqFK4 ONuxMPU0FxmzWuVOAWf4MwEJQFxVbHyDwi7uO0U= X-Google-Smtp-Source: ABdhPJwBBggZQn3Cyhx9MpkLxUrV54mwpTkKWiZ3HMj/AhMQ/g0tvj481AKklLUI58yK6d1G94I5lsGo6PcVNTlPsLk= X-Received: by 2002:a50:954b:0:b0:41a:c9cb:8778 with SMTP id v11-20020a50954b000000b0041ac9cb8778mr11187eda.165.1649892888391; Wed, 13 Apr 2022 16:34:48 -0700 (PDT) MIME-Version: 1.0 References: <20220317073652.kz3uuh6le6vbfod4@alap3.anarazel.de> <20220325.142256.1649716600998659084.horikyota.ntt@gmail.com> <20220325.172418.1055357550509939415.horikyota.ntt@gmail.com> <20220402082102.ojdd2e6cobsmljvh@alap3.anarazel.de> <20220404041516.cctrvpadhuriawlq@alap3.anarazel.de> <20220405030506.lfdhbu5zf4tzdpux@alap3.anarazel.de> <20220406030008.2qxipjxo776dwnqs@alap3.anarazel.de> In-Reply-To: <20220406030008.2qxipjxo776dwnqs@alap3.anarazel.de> From: "David G. Johnston" Date: Wed, 13 Apr 2022 16:34:32 -0700 Message-ID: Subject: Re: shared-memory based stats collector - v70 To: Andres Freund Cc: Kyotaro Horiguchi , Melanie Plageman , Justin Pryzby , Thomas Munro , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="00000000000087b13d05dc919f20" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000087b13d05dc919f20 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 5, 2022 at 8:00 PM Andres Freund wrote: > Here comes v70: > > One thing I just noticed while peeking at pg_stat_slru: The stats_reset column for my newly initdb'd cluster is showing me "2000-01-01 00:00:00" (v15). I was expecting null, though a non-null value restriction does make sense. Neither choice is documented though. Based upon my expectation I checked to see if v14 reported null, and thus this was a behavior change. v14 reports the initdb timestamp (e.g., 2022-04-13 23:26:48.349115+00) Can we document the non-null aspect of this value (pg_stat_database is happy being null, this seems to be a "fixed" type behavior) but have it continue to report initdb as its initial value? David J. --00000000000087b13d05dc919f20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 5, 2022 at 8:00 PM Andres Freund <andres@anarazel.de> wrote:
Here comes v70:


One thing I just= noticed while peeking at pg_stat_slru:

The stats_rese= t column for my newly initdb'd cluster=C2=A0is showing me "2000-01= -01 00:00:00" (v15).=C2=A0 I was expecting null, though a non-null val= ue restriction does make sense.=C2=A0 Neither choice is documented though.<= /div>

Based upon my expectation I checked to see if v14 repo= rted null, and thus this was a behavior change.=C2=A0 v14 reports the initd= b timestamp (e.g., 2022-04-13 23:26:48.349115+00)

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">Can we document the non-null aspect of this value (pg_stat_database is ha= ppy being null, this seems to be a "fixed" type behavior) but hav= e it continue to report initdb as its initial value?

D= avid J.

--00000000000087b13d05dc919f20--