On Tue, Feb 07, 2023 at 11:01:03PM -0800, Andres Freund wrote:
> Given that we already pay the price of multiple regress runs, and that
> jumbling is now really a core feature, perhaps we should enable
> pg_stat_statements in pg_upgrade or 027_stream_regress.pl? I'd hope it
> wouldn't add a meaningful amount of time? A tiny bit of verification at the
> end should also be ok.
Yeah, I have briefly mentioned this part upthread:
https://www.postgresql.org/message-id/Y8+BdCOjxykre5es@paquier.xyz
It would not, I guess, as long as pg_stat_statements.max is set large
enough in the TAP test. There are currently 21k~22k entries in the
regression database, much larger than the default of 5000 so this may
become an issue on small-ish machines if left untouched even in a TAP
test.
> Both pg_upgrade and 027_stream_regress.pl have some advantages. The former
> would test pg_upgrade interactions with shared_preload_libraries, the latter
> could do some basic checks of pg_stat_statements on a standby.
Yes, there could be more checks, potentially useful for both cases, so
I may choose both at the end of the day. Checking the consistency of
the contents of pg_stat_statements across a pg_upgrade run for the
same version may be one thing? I am not sure if it is that
interesting, TBH, still that's one idea :)
--
Michael
