Re: Add privileges test for pg_stat_statements to improve coverage

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

Re: Add privileges test for pg_stat_statements to improve coverage

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

Re: Add privileges test for pg_stat_statements to improve coverage

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

Re: Add privileges test for pg_stat_statements to improve coverage

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

Re: Add privileges test for pg_stat_statements to improve coverage

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

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 Coverag

Re: Output affected rows in EXPLAIN

Hi hackers, Indeed, I think it is a little confusing that when executing EXPLAIN(ANALYZE), even though an update is actually occurring, the commandtag of the update result is not returned. However, the manual also describes the information that will be affected when EXPLAIN (ANALYZE) is executed

Re: pg_get_indexdef() modification to use TxnSnapshot

Hi hackers, With '0001-pg_get_indexdef-modification-to-access-catalog-based.patch' patch, I confirmed that definition information can be collected even if the index is droped during pg_dump. The regression test (make check-world) has passed. I also tested the view definition for a similar prob

Re: pg_rewind: warn when checkpoint hasn't happened after promotion

hi Heikki, Thanks to mail, and thanks also for the commit(0a0500207a) to fix the document. I'm glad the problem was solved. Best Regards, Keisuke Kuroda NTT COMWARE 2023-02-27 16:33 に Heikki Linnakangas さんは書きました: On 16/11/2022 07:17, kuroda.keis...@nttcom.co.jp wrote: I fixed this last week i

Re: pg_rewind: warn when checkpoint hasn't happened after promotion

Hi, hackers The issue here is pg_rewind looks into control file to determine the soruce timeline, because the control file is not updated until the first checkpoint ends after promotion finishes, even though file blocks are already diverged. Even in that case history file for the new timeline i