Thread: Add privileges test for pg_stat_statements to improve coverage
Add privileges test for pg_stat_statements to improve coverage
From
kuroda.keisuke@nttcom.co.jp
Date:
Hi hackers, I proposal adding privileges test to improve test coverage of pg_stat_statements. ## test procedure ./configure --enable-coverage --enable-tap-tests --with-llvm CFLAGS=-O0 make check-world make coverage-html ## coverage before Line Coverage 74.0 %(702/949 lines) after Line Coverage 74.4 %(706/949 lines) Although the improvement is small, I think that test regarding privileges is necessary. As a side note, Initially, I was considering adding a test for dealloc. However, after reading the thread below, I confirmed that it is difficult to create tests due to differences due to endian. (https://www.postgresql.org/message-id/flat/40d1e4f2-835f-448f-a541-8ff5db75bf3d%40eisentraut.org) For this reason, I first added a test about privileges. Best Regards, Keisuke Kuroda NTT Comware
Attachment
On 2024/04/23 15:44, kuroda.keisuke@nttcom.co.jp wrote: > Hi hackers, > > I proposal adding privileges test to improve > test coverage of pg_stat_statements. +1 Here are the review comments: meson.build needs to be updated as well, like the Makefile. For the privileges test, should we explicitly set pg_stat_statements.track_utility at the start, as done in other pg_stat_statements tests, to make sure if utility command statistics are collected or not? +SELECT + CASE + WHEN queryid <> 0 THEN TRUE ELSE FALSE + END AS queryid_bool + ,query FROM pg_stat_statements ORDER BY query COLLATE "C"; Can't we simplify "CASE ... END" to just "queryid <> 0"? Should the test check not only queryid and query but also the statistics column like "calls"? Roles that aren't superusers or pg_read_all_stats should be able to see statistics but not query or queryid. So we should test that such roles can't see query or queryid but can see statistics. Thoughts? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Re: Add privileges test for pg_stat_statements to improve coverage
From
kuroda.keisuke@nttcom.co.jp
Date:
Hi Fujii-san, Thank you for your reply and comment! attach v2 fixed patch. > meson.build needs to be updated as well, like the Makefile. Yes. Update 'contrib/pg_stat_statements/meson.build'. > For the privileges test, should we explicitly set > pg_stat_statements.track_utility > at the start, as done in other pg_stat_statements tests, to make sure > if utility command statistics are collected or not? It certainly needs consideration. I think the results of the utility commands are not needed in privileges test. SET 'pg_stat_statements.track_utility = FALSE'. > Can't we simplify "CASE ... END" to just "queryid <> 0"? Yes. If we add "queryid <> 0" to the WHERE clause, we can get the same result. Change the SQL to the following: +SELECT query, calls, rows FROM pg_stat_statements + WHERE queryid <> 0 ORDER BY query COLLATE "C"; > Should the test check not only queryid and query but also > the statistics column like "calls"? Roles that aren't superusers > or pg_read_all_stats should be able to see statistics but not > query or queryid. So we should test that such roles can't see > query or queryid but can see statistics. Thoughts? I agree. We should test that such roles can't see query or queryid but can see statistics. Add the SQL to the test. Test that calls and rows are displayed even if the queryid is NULL. +-- regress_stats_user1 can read calls and rows +-- executed by other users +-- + +SET ROLE regress_stats_user1; +SELECT query, calls, rows FROM pg_stat_statements + WHERE queryid IS NULL ORDER BY query COLLATE "C"; Best Regards, Keisuke Kuroda NTT Comware
Attachment
On 2024/07/22 15:23, kuroda.keisuke@nttcom.co.jp wrote: > Hi Fujii-san, > Thank you for your reply and comment! > > attach v2 fixed patch. Thanks for updating the patch! +SELECT query, calls, rows FROM pg_stat_statements + WHERE queryid IS NULL ORDER BY query COLLATE "C"; Shouldn't we also include calls and rows in the ORDER BY clause? Without this, if there are multiple records with the same query but different calls or rows, the query result might be unstable. I believe this is causing the test failure reported by he PostgreSQL Patch Tester. http://cfbot.cputube.org/ https://cirrus-ci.com/task/4533613939654656 > Yes. > If we add "queryid <> 0" to the WHERE clause, we can get the same result. > Change the SQL to the following: > > +SELECT query, calls, rows FROM pg_stat_statements > + WHERE queryid <> 0 ORDER BY query COLLATE "C"; I was thinking of adding "queryid <> 0" in the SELECT clause instead of the WHERE clause. This way, we can verify if the query results are as expected regardless of the queryid value, including both queryid <> 0 and queryid = 0. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
On Tue, Jul 23, 2024 at 01:51:19AM +0900, Fujii Masao wrote: > +SELECT query, calls, rows FROM pg_stat_statements > + WHERE queryid IS NULL ORDER BY query COLLATE "C"; > > Shouldn't we also include calls and rows in the ORDER BY clause? > Without this, if there are multiple records with the same query > but different calls or rows, the query result might be unstable. > I believe this is causing the test failure reported by > he PostgreSQL Patch Tester. > > http://cfbot.cputube.org/ > https://cirrus-ci.com/task/4533613939654656 +SELECT query, calls, rows FROM pg_stat_statements + WHERE queryid IS NULL ORDER BY query COLLATE "C"; + query | calls | rows +--------------------------+-------+------ + <insufficient privilege> | 1 | 1 + <insufficient privilege> | 1 | 1 + <insufficient privilege> | 1 | 3 +(3 rows) I'd recommend to add a GROUP BY on calls and rows, with a count(query), rather than print the same row without the query text multiple times. +-- regress_stats_user2 can read query text and queryid +SET ROLE regress_stats_user2; +SELECT query, calls, rows FROM pg_stat_statements + WHERE queryid <> 0 ORDER BY query COLLATE "C"; + query | calls | rows +----------------------------------------------------+-------+------ + SELECT $1 AS "ONE" | 1 | 1 + SELECT $1+$2 AS "TWO" | 1 | 1 + SELECT pg_stat_statements_reset() IS NOT NULL AS t | 1 | 1 + SELECT query, calls, rows FROM pg_stat_statements +| 1 | 1 + WHERE queryid <> $1 ORDER BY query COLLATE "C" | | + SELECT query, calls, rows FROM pg_stat_statements +| 1 | 3 + WHERE queryid <> $1 ORDER BY query COLLATE "C" | | We have two entries here with the same query and the same query ID, because they have a different userid. Shouldn't this query reflect this information rather than have the reader guess it? This is going to require a join with pg_authid to grab the role name, and an ORDER BY on the role name. -- Michael
Attachment
Re: Add privileges test for pg_stat_statements to improve coverage
From
kuroda.keisuke@nttcom.co.jp
Date:
Hi Fujii-san, Thank you for your reply and comment! attach v3 fixed patch. > Shouldn't we also include calls and rows in the ORDER BY clause? > Without this, if there are multiple records with the same query > but different calls or rows, the query result might be unstable. > I believe this is causing the test failure reported by > he PostgreSQL Patch Tester. > I was thinking of adding "queryid <> 0" in the SELECT clause > instead of the WHERE clause. This way, we can verify if > the query results are as expected regardless of the queryid value, > including both queryid <> 0 and queryid = 0. It's exactly as you said. * Add calls and rows in the ORDER BY caluse. * Modify "queryid <> 0" in the SELECT clause. Modify test SQL belows, and the regress_stats_user1 check SQL only needs to be done once. +SELECT queryid <> 0 AS queryid_bool, query, calls, rows + FROM pg_stat_statements + ORDER BY query COLLATE "C", calls, rows; Best Regards, Keisuke Kuroda NTT Comware
Attachment
Re: Add privileges test for pg_stat_statements to improve coverage
From
kuroda.keisuke@nttcom.co.jp
Date:
Hi Michael-san,
Thank you for your reply and comment!
attach v4 fixed patch.
> We have two entries here with the same query and the same query ID,
> because they have a different userid. Shouldn't this query reflect
> this information rather than have the reader guess it? This is going
> to require a join with pg_authid to grab the role name, and an ORDER
> BY on the role name.
I agree.
The information of different userids is mixed up.
It is easier to understand if the role name is displayed.
Join with pg_roles (view of pg_authid) to output the role name.
> I'd recommend to add a GROUP BY on calls and rows, with a
> count(query), rather than print the same row without the query text
> multiple times.
Indeed, same row have been output multiple times.
If we use GROUP BY, we would expect the following.
```
SELECT r.rolname, ss.queryid <> 0 AS queryid_bool, count(ss.query),
ss.calls, ss.rows
FROM pg_stat_statements ss JOIN pg_roles r ON ss.userid = r.oid
GROUP BY r.rolname, queryid_bool, ss.calls, ss.rows
ORDER BY r.rolname, count(ss.query), ss.calls, ss.rows;
rolname | queryid_bool | count | calls | rows
---------------------+--------------+-------+-------+------
postgres | | 1 | 1 | 3
postgres | | 2 | 1 | 1
regress_stats_user1 | t | 1 | 1 | 1
(3 rows)
```
However, in this test I would like to see '<insufficient permissions>'
output
and the SQL text 'SELECT $1+$2 AS “TWO”' executed by
regress_stats_user1.
The attached patch executes the following SQL.
What do you think?
```
SELECT r.rolname, ss.queryid <> 0 AS queryid_bool, ss.query, ss.calls,
ss.rows
FROM pg_stat_statements ss JOIN pg_roles r ON ss.userid = r.oid
ORDER BY r.rolname, ss.query COLLATE "C", ss.calls, ss.rows;
rolname | queryid_bool | query | calls |
rows
---------------------+--------------+--------------------------+-------+------
postgres | | <insufficient privilege> | 1 |
1
postgres | | <insufficient privilege> | 1 |
1
postgres | | <insufficient privilege> | 1 |
3
regress_stats_user1 | t | SELECT $1+$2 AS "TWO" | 1 |
1
(4 rows)
```
Attachment
On 2024/07/23 10:40, kuroda.keisuke@nttcom.co.jp wrote: > I agree. > The information of different userids is mixed up. > It is easier to understand if the role name is displayed. > Join with pg_roles (view of pg_authid) to output the role name. + rolname | queryid_bool | query | calls | rows +---------------------+--------------+----------------------------------------------------+-------+------ + postgres | t | SELECT $1 AS "ONE" | 1 | 1 + postgres | t | SELECT pg_stat_statements_reset() IS NOT NULL AS t | 1 | 1 + regress_stats_user1 | t | SELECT $1+$2 AS "TWO" | 1 | 1 Using "postgres" as the default superuser name can cause instability. This is why the Patch Tester reports now test failures again. You should create and use a different superuser, such as "regress_stats_superuser." Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Re: Add privileges test for pg_stat_statements to improve coverage
From
kuroda.keisuke@nttcom.co.jp
Date:
Hi Fujii-san, Thank you for your comment! attach v5 fixed patch. > Using "postgres" as the default superuser name can cause instability. > This is why the Patch Tester reports now test failures again. > You should create and use a different superuser, such as > "regress_stats_superuser." I understand. Add "regress_stats_superuser" for test by superuser. Best Regards, Keisuke Kuroda NTT Comware
Attachment
On 2024/07/23 15:02, kuroda.keisuke@nttcom.co.jp wrote: > Hi Fujii-san, > Thank you for your comment! > > attach v5 fixed patch. > >> Using "postgres" as the default superuser name can cause instability. >> This is why the Patch Tester reports now test failures again. >> You should create and use a different superuser, such as >> "regress_stats_superuser." > > I understand. > Add "regress_stats_superuser" for test by superuser. Thanks for updating the patch! I've slightly modified the comments in the regression tests for clarity. Attached is the v6 patch. If there are no objections, I will push this version. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
Attachment
Re: Add privileges test for pg_stat_statements to improve coverage
From
kuroda.keisuke@nttcom.co.jp
Date:
> I've slightly modified the comments in the regression tests for > clarity. > Attached is the v6 patch. If there are no objections, > I will push this version. Thank you for updating patch! I have no objection. Best Regards, Keisuke Kuroda NTT Comware
On 2024/07/24 10:23, kuroda.keisuke@nttcom.co.jp wrote: >> I've slightly modified the comments in the regression tests for clarity. >> Attached is the v6 patch. If there are no objections, >> I will push this version. > > Thank you for updating patch! I have no objection. Pushed. Thanks! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION