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
