Date: Sun, 20 Mar 2022 09:58:31 -0700
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	Ibrar Ahmed <ibrar.ahmad@gmail.com>, masao.fujii@oss.nttdata.com,
	gkokolatos@protonmail.com,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: shared-memory based stats collector - v66
Message-ID: <20220320165831.msddvqz2nfrptyps@alap3.anarazel.de>
[IFrom: Andres Freund <andres@anarazel.de>
References: <CALtqXTdyEioaush=41y=PL96oPv-PHa6G9quFMY2kUd-WZzAcw@mail.gmail.com>
 <20210721.170949.572695811364264016.horikyota.ntt@gmail.com>
 <20210721155802.6bhjy3oe7feapgwa@alap3.anarazel.de>
 <20210726.175201.1255224992745035759.horikyota.ntt@gmail.com>
 <20210727012754.dmd5feciccnkd6g2@alap3.anarazel.de>
 <20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de>
 <20220317073652.kz3uuh6le6vbfod4@alap3.anarazel.de>
 <CAAKRu_aNxL1WegCa45r=VAViCLnpOU7uNC7bTtGw+=QAPyYivw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAKRu_aNxL1WegCa45r=VAViCLnpOU7uNC7bTtGw+=QAPyYivw@mail.gmail.com>
From: Andres Freund <andres@anarazel.de>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: <https://www.postgresql.org/message-id/20220320165831.msddvqz2nfrptyps%40alap3.anarazel.de>
Precedence: bulk

Hi,

On 2022-03-20 12:32:39 -0400, Melanie Plageman wrote:
> Attached is a TAP test to check that stats are cleaned up on a physical
> replica after the objects they concern are dropped on the primary.

Thanks!


> I'm not sure that the extra force next flush on standby is needed after
> drop on primary since drop should report stats and I wait for catchup.

A drop doesn't force stats in other sessions to be flushed immediately, so
unless I misunderstand, yes, it's needed.


> Also, I don't think the tests with DROP SCHEMA actually exercise another
> code path, so it might be worth cutting those.

> +/*
> + * Checks for presence of stats for object with provided object oid of kind
> + * specified in the type string in database of provided database oid.
> + *
> + * For subscription stats, only the objoid will be used. For database stats,
> + * only the dboid will be used. The value passed in for the unused parameter is
> + * discarded.
> + * TODO: should it be 'pg_stat_stats_present' instead of 'pg_stat_stats_exist'?
> + */
> +Datum
> +pg_stat_stats_exist(PG_FUNCTION_ARGS)

Should we revoke stats for this one from PUBLIC (similar to the reset functions)?


> +# Set track_functions to all on standby
> +$node_standby->append_conf('postgresql.conf', "track_functions = 'all'");

That should already be set, cloning from the primary includes the
configuration from that point in time.

> +$node_standby->restart;

FWIW, it'd also only require a reload....

Greetings,

Andres Freund