Force testing of query jumbling code in TAP tests

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Force testing of query jumbling code in TAP tests
Date: 2023-02-13 05:00:36
Message-ID: Y+nD9LN70w+8eaG9@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

As mentioned two times on this thread, there is not much coverage for
the query jumbling code, even if it is in core:
https://www.postgresql.org/message-id/Y5BHOUhX3zTH/ig6(at)paquier(dot)xyz

Ths issue is that we have the options to enable it, but only
pg_stat_statements is able to enable and stress it. This causes
coverage to be missed for all query patterns that are not covered
directly by pg_stat_statements, like XML expressions, various DML
patterns, etc. More aggressive testing would also ensure that no
nodes are marked as no_query_jumble while they should be included in a
computation.

Attached is a patch to improve that. The main regression database is
able to cover everything, basically, so I'd like to propose the
addition of some extra configuration in 027_stream_regress.pl to
enable pg_stat_statements. This could be added in the pg_upgrade
tests, but that felt a bit less adapted here. Or can people think
about cases where checking pg_stat_statements makes more sense after
an upgrade or on a standby? One thing that makes sense for a standby
is to check that the contents of pg_stat_statements are empty?

With this addition, the query jumbling gets covered at 95%~, while
https://coverage.postgresql.org/src/backend/nodes/index.html reports
currently 35%.

Thoughts or comments?
--
Michael

Attachment Content-Type Size
query_jumble_test.patch text/x-diff 1.5 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2023-02-13 06:01:03 Re: Introduce a new view for checkpointer related stats
Previous Message Peter Smith 2023-02-13 04:55:39 Re: Support logical replication of DDLs