On 2024/07/24 10:23, kuroda.keis...@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,
--
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/23 15:02, kuroda.keis...@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 s
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
On 2024/07/23 10:40, kuroda.keis...@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 |
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
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
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
On 2024/07/22 15:23, kuroda.keis...@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 inclu
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 d
On 2024/04/23 15:44, kuroda.keis...@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 explicitl
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 Coverag
12 matches
Mail list logo
