Some cleanup of pg_stat_statements tests

Started by Michael Paquier3 months ago5 messageshackers
Jump to latest
#1Michael Paquier
michael@paquier.xyz

Hi all,

While looking at this area of the code, I have noticed that the new
"squashing" test is not consistent with the rest of the test suite,
re-creating the extension for nothing.

The structure of the test is to have the "cleanup" phase second to
last, so as there is no need to create multiple times the extensions.

In passing, I'd like to suggest that REGRESS in the Makefile uses one
item per line, to minimize diffs when we add new stuff.

Any thoughts or objections about the attached?
Thanks,
--
Michael

Attachments:

0001-pg_stat_statements-Clean-up-test-logic.patchtext/x-diff; charset=us-asciiDownload+20-7
#2Chao Li
li.evan.chao@gmail.com
In reply to: Michael Paquier (#1)
Re: Some cleanup of pg_stat_statements tests

On Jan 20, 2026, at 07:33, Michael Paquier <michael@paquier.xyz> wrote:

Hi all,

While looking at this area of the code, I have noticed that the new
"squashing" test is not consistent with the rest of the test suite,
re-creating the extension for nothing.

The structure of the test is to have the "cleanup" phase second to
last, so as there is no need to create multiple times the extensions.

In passing, I'd like to suggest that REGRESS in the Makefile uses one
item per line, to minimize diffs when we add new stuff.

Any thoughts or objections about the attached?
Thanks,
--
Michael
<0001-pg_stat_statements-Clean-up-test-logic.patch>

LGTM. And I tried to the test and saw squashing is now before cleanup:

```
# +++ regress check in contrib/pg_stat_statements +++
# initializing database system by copying initdb template
# using temp instance on port 58928 with PID 2069
ok 1 - select 68 ms
ok 2 - dml 23 ms
ok 3 - cursors 14 ms
ok 4 - utility 76 ms
ok 5 - level_tracking 56 ms
ok 6 - planning 14 ms
ok 7 - user_activity 15 ms
ok 8 - wal 13 ms
ok 9 - entry_timestamp 14 ms
ok 10 - privileges 15 ms
ok 11 - extended 15 ms
ok 12 - parallel 16 ms
ok 13 - plancache 16 ms
ok 14 - squashing 39 ms
ok 15 - cleanup 10 ms
ok 16 - oldextversions 52 ms
1..16
# All 16 tests passed.
```

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

#3zengman
zengman@halodbtech.com
In reply to: Michael Paquier (#1)
Re:Some cleanup of pg_stat_statements tests

In passing, I'd like to suggest that REGRESS in the Makefile uses one
item per line, to minimize diffs when we add new stuff.
Any thoughts or objections about the attached?

Hi,

I noticed that wal entry_timestamp is still on the same line. Should we split it here as well?

--
Regards,
Man Zeng
www.openhalo.org

#4Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Michael Paquier (#1)
Re: Some cleanup of pg_stat_statements tests

On 2026-Jan-20, Michael Paquier wrote:

While looking at this area of the code, I have noticed that the new
"squashing" test is not consistent with the rest of the test suite,
re-creating the extension for nothing.

The structure of the test is to have the "cleanup" phase second to
last, so as there is no need to create multiple times the extensions.

Huh, yeah, agreed on this change.

In passing, I'd like to suggest that REGRESS in the Makefile uses one
item per line, to minimize diffs when we add new stuff.

Absolutely.

Any thoughts or objections about the attached?

No objections here.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Java is clearly an example of money oriented programming" (A. Stepanov)

#5Michael Paquier
michael@paquier.xyz
In reply to: Alvaro Herrera (#4)
Re: Some cleanup of pg_stat_statements tests

On Tue, Jan 20, 2026 at 01:36:47PM +0100, Alvaro Herrera wrote:

On 2026-Jan-20, Michael Paquier wrote:

Any thoughts or objections about the attached?

No objections here.

Thanks for looking, done as f9afd56218af.
--
Michael