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+bdcojxykre...@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
signature.asc
Description: PGP signature
