Обсуждение: Add privileges test for pg_stat_statements to improve coverage

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

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

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

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

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

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)
```

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

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

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

> 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