Force testing of query jumbling code in TAP tests
| От | Michael Paquier |
|---|---|
| Тема | Force testing of query jumbling code in TAP tests |
| Дата | |
| Msg-id | Y+nD9LN70w+8eaG9@paquier.xyz обсуждение исходный текст |
| Ответы |
Re: Force testing of query jumbling code in TAP tests
|
| Список | 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@paquier.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
Вложения
В списке pgsql-hackers по дате отправления: