RE: (LOCK TABLE options) “ONLY” and “NOWAIT” are not yet implemented

>-Original Message- >From: Fujii Masao >Sent: Monday, October 4, 2021 1:59 PM >To: bt21tanigaway ; RDH 加藤 慎也/Kato, >Shinya (NTT DATA) >Cc: pgsql-hackers@lists.postgresql.org >Subject: Re: (LOCK TABLE options) “ONLY” and “NOWAIT” are not yet >implemented > > > >On 2021/10/04 11:17, bt21tan

RE: (LOCK TABLE options) “ONLY” and “NOWAIT” are not yet implemented

>Thank you for your feedback. >I might have added whitespace when I was checking the patch file. >I attach a new patch to this mail. Thank you for the update! > else if (Matches("LOCK", MatchAny, "IN", "ACCESS|ROW") || >- Matches("LOCK", "TABLE", MatchAny, "IN", "ACCESS

RE: (LOCK TABLE options) “ONLY” and “NOWAIT” are not yet implemented

>-Original Message- >From: bt21tanigaway >Sent: Tuesday, September 28, 2021 5:06 PM >To: Fujii Masao ; >pgsql-hackers@lists.postgresql.org >Subject: Re: (LOCK TABLE options) “ONLY” and “NOWAIT” are not yet >implemented > >2021-09-28 17:03 に bt21tanigaway さんは書きました: >> 2021-09-28 16:36 に Fuj

RE: [PATCH] New default role allowing to change per-role/database settings

>Thanks for letting me know, I've attached a rebased v4 of this patch, no other >changes. I tried it, but when I used set command, tab completion did not work properly and an error occurred. --- postgres=> \conninfo You are connected to database "postgres" as user "aaa" via socket in "/tmp" at p

fix DECLARE tab completion

Hi! In the discussion of [1], the option ASENSITIVE was added to DECLARE. I have improved its tab completion and attached a patch. Do you think? [1] https://www.postgresql.org/message-id/flat/96ee8b30-9889-9e1b-b053-90e10c050e85%40enterprisedb.com Regards, Shinya Kato fix_declare_tab_complet

RE: [PATCH] expand the units that pg_size_pretty supports on output

>I had not really looked at the patch, but if there's a cleanup portion to the >same >patch as you're adding the YB too, then maybe it's worth separating those out >into another patch so that the two can be considered independently. I agree with this opinion. It seems to me that we should think a

RE: [PATCH] expand the units that pg_size_pretty supports on output

>> I don't see the need to extend the unit to YB. >> What use case do you have in mind? > >Practical or no, I saw no reason not to support all defined units. I assume >we’ll >get to a need sooner or later. :) Thank you for your reply! Hmmm, I didn't think YB was necessary, but what do others thin

RE: psql - factor out echo code

>> Wouldn't it be better to comment it like any other function? > >Sure. Attached. Thank you for your revision. I think this patch is good, so I will move it to ready for committer. Best regards, Shinya Kato

RE: [PATCH] expand the units that pg_size_pretty supports on output

>From: David Christensen >Sent: Friday, June 4, 2021 4:18 AM >To: PostgreSQL-development >Subject: Re: [PATCH] expand the units that pg_size_pretty supports on output > >New versions attached to address the initial CF feedback and rebase on HEAD as >of now. > >0001-Expand-the-units-that-pg_size

RE: psql - factor out echo code

>-Original Message- >From: Fabien COELHO >Sent: Sunday, May 30, 2021 6:10 PM >To: PostgreSQL Developers >Subject: psql - factor out echo code > > >While working on something in "psql/common.c" I noticed some triplicated code, >including a long translatable string. This minor patch refacto

RE: Fix pg_checksums progress report

>-Original Message- >From: Fujii Masao >Sent: Friday, April 2, 2021 6:03 PM >To: Michael Paquier ; shinya11.k...@nttdata.com >Cc: pgsql-hack...@postgresql.org >Subject: Re: Fix pg_checksums progress report > > > >On 2021/04/02 16:47, Michael Paquier wrote: >> On Fri, Apr 02, 2021 at 07:30:

RE: Fix pg_checksums progress report

>-Original Message- >From: Fujii Masao >Sent: Friday, April 2, 2021 2:39 PM >To: shinya11.k...@nttdata.com; pgsql-hack...@postgresql.org >Subject: Re: Fix pg_checksums progress report > > > >On 2021/04/02 14:23, shinya11.k...@nttdata.com wrote: >> Hi, >> >> I found a problem with the pg_ch

Fix pg_checksums progress report

Hi, I found a problem with the pg_checksums.c. The total_size is calculated by scanning the directory. The current_size is calculated by scanning the files, but the current_size does not include the size of NewPages. This may cause pg_checksums progress report to not be 100%. I have attached a

RE: Wrong statistics for size of XLOG_SWITCH during pg_waldump.

>-Original Message- >From: Fujii Masao >Sent: Monday, March 22, 2021 11:22 AM >To: shinya11.k...@nttdata.com; da...@pgmasters.net; movead...@highgo.ca >Cc: pgsql-hack...@postgresql.org; and...@anarazel.de; mich...@paquier.xyz; >ahsan.h...@highgo.ca; horikyota@gmail.com >Subject: Re: Wr

RE: Wrong statistics for size of XLOG_SWITCH during pg_waldump.

>>>But 0 value maybe looks strange, so in current version I show it like >below: >>>Type N (%) Record size (%) FPI size (%) Combined size (%) >>> - --- --- --- --- - --- ... >>>XLOG/SWITCH_JUNK - ( -) 11006248 ( 72.26) - ( -) 11006248 ( 65.78) >>>Transaction/COMMIT

RE: [PATCH] Feature improvement for CLOSE, FETCH, MOVE tab completion

>On Thu, Jan 7, 2021 at 1:30 PM Fujii Masao > wrote: >> >> On 2021/01/07 12:42, Masahiko Sawada wrote: >> > On Thu, Jan 7, 2021 at 10:59 AM Fujii Masao >> > wrote: >> >> >> >> On 2021/01/07 10:01, Masahiko Sawada wrote: >> >>> On Wed, Jan 6, 2021 at 3:37 PM >> >>> wrote: >> >> > +#def

RE: Wrong statistics for size of XLOG_SWITCH during pg_waldump.

>Thanks for review, and sorry for reply so later. > >>I reviewed the patch and found some problems. >>>+ if(startSegNo != endSegNo) >>>+ else if(record->ReadRecPtr / XLOG_BLCKSZ != >>>+ if(rmid == RM_XLOG_ID && info == XLOG_SWITCH) >>>+ if(ri == RM_XLOG_ID) >>>+ if(info == XLOG_SWITCH) >>You need t

RE: [PATCH] Feature improvement for CLOSE, FETCH, MOVE tab completion

>+#define Query_for_list_of_cursors \ >+" SELECT name FROM pg_cursors"\ > >This query should be the following? > >" SELECT pg_catalog.quote_ident(name) "\ >" FROM pg_catalog.pg_cursors "\ >" WHERE substring(pg_catalog.quote_ident(name),1,%d)='%s'" > >+/* CLOSE */ >+ else if (Matches("CLOSE"

RE: [PATCH] Feature improvement for CLOSE, FETCH, MOVE tab completion

Thank you for your review! I fixed some codes and attach a new patch. >When I applied the patch, I got the following whitespace warnings: > >$ git apply ~/patches/fix_tab_complete_close_fetch_move.patch >/home/masahiko/patches/fix_tab_complete_close_fetch_move.patch:40: >indent with spaces. >

RE: Wrong statistics for size of XLOG_SWITCH during pg_waldump.

Thanks for the reply. > Mr.Horiguchi. I reviewed the patch and found some problems. >+ if(startSegNo != endSegNo) >+ else if(record->ReadRecPtr / XLOG_BLCKSZ != >+ if(rmid == RM_XLOG_ID && info == XLOG_SWITCH) >+ if(ri == RM_XLOG_ID) >+ if(info == XLOG_SWITCH) You need to put a space after the "i

[PATCH] Feature improvement for CLOSE, FETCH, MOVE tab completion

Hi! I created a patch for improving CLOSE, FETCH, MOVE tab completion. Specifically, I add CLOSE, FETCH, MOVE tab completion for completing a predefined cursors. Regards, Shinya Kato fix_tab_complete_close_fetch_move.patch Description: fix_tab_complete_close_fetch_move.patch

RE: Wrong statistics for size of XLOG_SWITCH during pg_waldump.

When I execute pg_waldump, I found that XLOG/SWITCH_JUNK appears twice. Is this problem solved by the way of correcting the previously discussed Transaction/COMMIT? $ ../bin/pg_waldump --stats=record ../data/pg_wal/00010001 Type N (%)