Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONFrom 7aaa813665ed159725998988431be15687b01494 Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Fri, 21 Apr 2023 00:34:39 +0900
Subject: [PATCH v1] doc: Add documentation for PGLOADBALANCEHOSTS
On 2023/04/21 2:14, Jelte Fennema wrote:
Ah, yeah it seems I forgot to document that one. LGTM
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Hi,
I'd like to propose to mark reloptions as indexterms, like GUC,
so that users can more easily search the pages describing
a reloption in document. Attached is the patch which does this.
Is this helpful? Thought?
Regards,
--
Fujii Masao
reloption-doc-v1.patch
Description: Binary data
On Wed, Apr 10, 2019 at 4:11 AM Alvaro Herrera wrote:
>
> On 2019-Apr-10, Fujii Masao wrote:
>
> > Hi,
> >
> > I'd like to propose to mark reloptions as indexterms, like GUC,
> > so that users can more easily search the pages describing
> > a relopt
On Fri, Apr 12, 2019 at 12:54 PM Alvaro Herrera
wrote:
>
> On 2019-Apr-12, Fujii Masao wrote:
>
> > On Wed, Apr 10, 2019 at 4:11 AM Alvaro Herrera
> > wrote:
> > >
> > > On 2019-Apr-10, Fujii Masao wrote:
> > >
> > > > Hi,
> >
+1
While reading the doc for index reloptins, I found that there is
no information about the type for each index reloption in the doc.
Probably it's worth adding that information, like the doc for table
reloptions have.
Regards,
--
Fujii Masao
On Sat, Apr 13, 2019 at 1:30 AM Alvaro Herrera wrote:
>
> On 2019-Apr-12, Fujii Masao wrote:
>
>
> > OTOH, originally I thought that the following style is smarter.
> >
> > xxx
> > configuration parameter, XXX
> > storage parameter, St
On Tue, Apr 16, 2019 at 12:35 AM Alvaro Herrera
wrote:
>
> On 2019-Apr-16, Fujii Masao wrote:
>
> > On Sat, Apr 13, 2019 at 1:30 AM Alvaro Herrera
> > wrote:
> > >
> > > On 2019-Apr-12, Fujii Masao wrote:
> > >
> > >
> > >
On Tue, Apr 16, 2019 at 1:15 AM Alvaro Herrera wrote:
>
> On 2019-Apr-16, Fujii Masao wrote:
>
> > On Tue, Apr 16, 2019 at 12:35 AM Alvaro Herrera
> > wrote:
>
> > > For autovacuum it says "configuration
> > > parameters" rather than "c
On Tue, Apr 16, 2019 at 12:26 PM Michael Paquier wrote:
>
> On Tue, Apr 16, 2019 at 12:14:01AM +0900, Fujii Masao wrote:
> > So I used tag again for the above style if both reloption
> > and guc with the same parameter name exist. Attached is the updated
> > version of th
cuted during recovery, and which should be described in the doc.
So I think that the attached patch should be pushed. Thought?
Probably the patch needs to be back-patched to 9.6 where non-exclusive
backup API was added.
Regards,
--
Fujii Masao
backup-doc.patch
Description: Binary data
On Fri, Apr 19, 2019 at 11:36 AM Michael Paquier wrote:
>
> On Fri, Apr 19, 2019 at 12:38:23AM +0900, Fujii Masao wrote:
> > Regarding backup control functions, the func.sgml describes as above.
> > But non-exclusive pg_start_backup and pg_stop_backup can also be
> > execu
old commit 8c843fff2d,
but seems the documentation had not been updated unfortunately a long time.
Attached patch replaces 0001 with 00010001
in the above description.
This patch needs to be back-patched to all the supported versions.
Regards,
--
Fujii Masao
the similar description,
for example, pg_receivewal.sgml, func.sgml and high-availability.sgml.
Isn't it better to update also them at the same time?
Any objections from others?
No.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT
On 2020/04/28 17:15, Daniel Gustafsson wrote:
On 28 Apr 2020, at 07:22, Fujii Masao wrote:
On 2020/04/28 13:37, Michael Paquier wrote:
On Mon, Apr 27, 2020 at 12:16:41PM +0200, Daniel Gustafsson wrote:
Based on a recent conversation about backups I had I propose a small tweak to
the
x27;s better to reorder those columns in a consistent
with the view definition. Patch attached. Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/doc/src/sgml/pgstatstatements.sgml
b/doc/src
On 2020/05/14 0:41, Tom Lane wrote:
Fujii Masao writes:
In pg_stat_statements docs, the columns about WAL activity are put
in the table in the order of wal_bytes, wal_records and wal_fpi. But
in the definition of pg_stat_statements view, wal_bytes is put last.
So I think that it's bett
pg_stat_slru view. Attached patch fixes this issue.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index acc6e2bc31..4810c4a0f1 100644
--- a/doc/src/sgml
On 2020/05/20 11:05, Tom Lane wrote:
Fujii Masao writes:
In monitoring.sgml, there are the tables and corresponding descriptions
for pg_stat_user_functions and pg_stat_slru views. I found that those
descriptions are located in opposite places. For example, the description
for
On 2020/05/20 22:32, Tom Lane wrote:
Fujii Masao writes:
Also I don't like that all the stats views are packed in one section
currently. Which makes the docs difficult to read, I'm afraid. Thought?
If we change the layout entirely, at the same time, what about separating
each
On 2020/05/21 4:53, Tom Lane wrote:
Fujii Masao writes:
On 2020/05/20 22:32, Tom Lane wrote:
OK by me --- that, too, would be more like the existing catalogs
chapter.
Yeah, so I'd like to propose the attached patch.
Hmmm ... I'm not exactly convinced about sticking xreflabel
On 2020/05/22 22:35, Fujii Masao wrote:
On 2020/05/21 4:53, Tom Lane wrote:
Fujii Masao writes:
On 2020/05/20 22:32, Tom Lane wrote:
OK by me --- that, too, would be more like the existing catalogs
chapter.
Yeah, so I'd like to propose the attached patch.
Hmmm ... I'm n
On 2020/05/25 14:23, Fujii Masao wrote:
On 2020/05/22 22:35, Fujii Masao wrote:
On 2020/05/21 4:53, Tom Lane wrote:
Fujii Masao writes:
On 2020/05/20 22:32, Tom Lane wrote:
OK by me --- that, too, would be more like the existing catalogs
chapter.
Yeah, so I'd like to propos
Hi,
The group of wal_init_zero and wal_recycle is WAL_SETTINGS in guc.c,
but their descriptions are located in "19.6. Replication"/"19.6.1. Sending
Servers" section. This seems a documentation bug. They should be located
in "19.5. Write Ahead Log"/"19.5.1. Sett
On 2020/05/28 8:43, Thomas Munro wrote:
On Wed, May 27, 2020 at 7:09 PM Simon Riggs wrote:
On Wed, 27 May 2020 at 04:27, Fujii Masao wrote:
Hi,
The group of wal_init_zero and wal_recycle is WAL_SETTINGS in guc.c,
but their descriptions are located in "19.6. Replication"/"
On 2020/05/27 12:17, Fujii Masao wrote:
On 2020/05/25 14:23, Fujii Masao wrote:
On 2020/05/22 22:35, Fujii Masao wrote:
On 2020/05/21 4:53, Tom Lane wrote:
Fujii Masao writes:
On 2020/05/20 22:32, Tom Lane wrote:
OK by me --- that, too, would be more like the existing catalogs
On 2020/05/29 13:13, Fujii Masao wrote:
On 2020/05/28 8:43, Thomas Munro wrote:
On Wed, May 27, 2020 at 7:09 PM Simon Riggs wrote:
On Wed, 27 May 2020 at 04:27, Fujii Masao wrote:
Hi,
The group of wal_init_zero and wal_recycle is WAL_SETTINGS in guc.c,
but their descriptions are
On 2020/06/02 14:25, Fujii Masao wrote:
On 2020/05/29 13:13, Fujii Masao wrote:
On 2020/05/28 8:43, Thomas Munro wrote:
On Wed, May 27, 2020 at 7:09 PM Simon Riggs wrote:
On Wed, 27 May 2020 at 04:27, Fujii Masao wrote:
Hi,
The group of wal_init_zero and wal_recycle is
more than
max_slot_wal_keep_size from the current LSN.
Patch attached.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 700271fd40..bf326cf533 100644
--- a/do
On 2020/06/17 23:47, Fujii Masao wrote:
Hi,
The document explains that restart_lsn column in pg_replication_slots view is:
The address (LSN) of oldest WAL which still might be required by
the consumer of this slot and thus won't be automatically removed
during checkp
On 2020/06/25 10:00, Alvaro Herrera wrote:
On 2020-Jun-17, Fujii Masao wrote:
The document explains that restart_lsn column in pg_replication_slots view is:
The address (LSN) of oldest WAL which still might be required by
the consumer of this slot and thus won't be automati
On 2020/06/25 14:48, Fujii Masao wrote:
On 2020/06/25 10:00, Alvaro Herrera wrote:
On 2020-Jun-17, Fujii Masao wrote:
The document explains that restart_lsn column in pg_replication_slots view is:
The address (LSN) of oldest WAL which still might be required by
the consumer of
On 2020/06/30 14:56, Fujii Masao wrote:
On 2020/06/25 14:48, Fujii Masao wrote:
On 2020/06/25 10:00, Alvaro Herrera wrote:
On 2020-Jun-17, Fujii Masao wrote:
The document explains that restart_lsn column in pg_replication_slots view is:
The address (LSN) of oldest WAL which
er versions,
support for recovery.conf has been removed, requiring roughly the
creation of standby.signal with all recovery parameters set in
postgresql.conf if you want to set up a standby.
--
Michael
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
.
This patch fixes the DDL in the document of file-fdw.
Thanks for the patch! LGTM. I will commit it.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
the doc page for file_fdw with an
extra sentence, but I agree that it is more complex to understand that
than a simple copy-paste from the doc itself.
So ISTM our consensus is to apply the proposed patch.
Barring any objection, I will do that.
Regards,
--
Fujii Masao
Advanced Computing
On 2020/09/15 16:59, Michael Paquier wrote:
On Tue, Sep 15, 2020 at 04:43:39PM +0900, Fujii Masao wrote:
So ISTM our consensus is to apply the proposed patch.
Barring any objection, I will do that.
No objections from here at the end.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced
(Which is also a bit confusing, I would expect a default to apply when the
option is specified without an argument, as opposed to when the option itself
it is not specified )
As far as I recall, we discussed that in [1] and gave up doing that.
Regards,
[1]
https://postgr.es/m/1338235863.249
, from the index. So what about adding
new pointer to the section for each view in the index?
Patch attached.
BTW, other stats views have both pointers in the index.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff
r_participation configuration parameter , Other Planner Options
pg_trgm.strict_word_similarity_threshold configuration parameter , GUC
Parameters
pg_trgm.word_similarity_threshold configuration parameter , GUC Parameters
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research
according to the section
"Infinite (Unbounded) Ranges" (*1), we already call "lower/upper bound
omitted" just infinite. So I don't think the current description is incorrect.
(*1)
https://www.postgresql.org/docs/devel/rangetypes.html#RANGETYPES-INFINITE
Regards,
--
Fujii
On 2020/11/22 6:32, Euler Taveira wrote:
On Mon, 16 Nov 2020 at 12:26, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
I found that only the following three index items have " ,"
(i.e., space + comma) in the docs. This is not harmful and
is very minor iss
same situation at, for example,
the section and indexterm of pg_stat_database. If I'm missing something,
could you tell me why the zone attribute is necessary in this case?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
und the zone set for indexterm after , so you may
be right.
So you agree not to add zone attribute in this case?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
#x27;t found the zone set for indexterm after , so you may
be right.
So you agree not to add zone attribute in this case?
Yes, I think it's nice.
So I pushed the patch. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
en. Others may have comments to
offer, so I'll first wait a bit before applying my suggestion from
upthread.
I agree with this change.
But I have one question; why do those commands use different
archive directories? Isn't it better to use the same one?
Regards,
--
Fujii Masao
Adva
On 2021/02/25 15:54, Michael Paquier wrote:
On Wed, Feb 24, 2021 at 08:15:59PM +0900, Fujii Masao wrote:
But I have one question; why do those commands use different
archive directories? Isn't it better to use the same one?
storage.sgml uses /var/lib/pgsql/data for the location of the
}
+{ INCLUDING | EXCLUDING } { COMMENTS | COMPRESSION | CONSTRAINTS | DEFAULTS |
GENERATED | IDENTITY | INDEXES | STATISTICS | STORAGE | ALL }
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
diff --git a/doc/src/sgml/ref
On 2021/04/15 11:54, Michael Paquier wrote:
On Wed, Apr 14, 2021 at 11:46:58PM +0900, Fujii Masao wrote:
The syntax for like_option in CREATE TABLE docs seems to forget to mention
INCLUDING COMPRESSION option. I think the following fix is necessary.
Patch attached.
-{ INCLUDING | EXCLUDING
On 2021/04/16 10:20, Michael Paquier wrote:
On Thu, Apr 15, 2021 at 11:24:07PM +0900, Fujii Masao wrote:
I'm not sure why. But +1 to make them in alphabetical order.
Patch attached.
LGTM.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Researc
index, tuples_returned is the number of index entries returned by
* the index AM, while tuples_fetched is the number of tuples successfully
* fetched by heap_fetch under the control of simple indexscans for this index.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research an
On 2021/05/17 18:58, Masahiro Ikeda wrote:
On 2021/05/17 15:32, Fujii Masao wrote:
On 2021/05/14 17:00, Masahiro Ikeda wrote:
Hi,
I worried the difference between "tup_returned" and "tup_fetched" in
pg_stat_database. I assumed that "tup_returned" m
On 2021/05/18 13:20, Masahiro Ikeda wrote:
On 2021/05/17 20:46, Fujii Masao wrote:
On 2021/05/17 18:58, Masahiro Ikeda wrote:
On 2021/05/17 15:32, Fujii Masao wrote:
On 2021/05/14 17:00, Masahiro Ikeda wrote:
Hi,
I worried the difference between "tup_returned" and &q
On 2021/05/18 18:23, Masahiro Ikeda wrote:
On 2021/05/18 16:01, Fujii Masao wrote:
On 2021/05/18 13:20, Masahiro Ikeda wrote:
Tid Range Scan increments the tup_returned, and
pg_stat_all_tables.seq_tup_read is also incremented. I thought it's ok because
Tid Range Scan is like seque
On 2021/05/20 9:46, Masahiro Ikeda wrote:
On 2021/05/18 20:10, Fujii Masao wrote:
On 2021/05/18 18:23, Masahiro Ikeda wrote:
On 2021/05/18 16:01, Fujii Masao wrote:
On 2021/05/18 13:20, Masahiro Ikeda wrote:
Tid Range Scan increments the tup_returned, and
On 2021/05/20 17:38, Masahiro Ikeda wrote:
On 2021/05/20 17:00, Fujii Masao wrote:
On 2021/05/20 9:46, Masahiro Ikeda wrote:
On 2021/05/18 20:10, Fujii Masao wrote:
pg_stat_database.tup_fetched:
Number of index entries returned by scans on indexes in this database
Is this the sum of
cs, "floating point" should be
used for the sake of consistenty, instead?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
ch! Pushed.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
On 2021/05/24 11:37, Masahiro Ikeda wrote:
Thanks for checking the patch!
I thought this patch will be applied in V15 dev cycle.
OK. I added the patch to the next CF.
https://commitfest.postgresql.org/33/3130/
I pushed the patch to 15dev. Thanks!
Regards,
--
Fujii Masao
Advanced
to them.
- Auxiliary process
- Startup process
- WAL receiver
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONdiff --git a/doc/src/sgml/glossary.sgml b/doc/src/sgml/glossary.sgml
index 0c88988fa6..0fea6b4ab3 100644
--- a/do
On 2022/01/08 1:41, Tom Lane wrote:
Fujii Masao writes:
In glossary, the title of each term about process seems to consist of the process name and
"(process)", e.g., Checkpointer (process). But I found that "(process)" is missing for
the following three terms about
Hi,
The maximum number of backtrace frames logged by backtrace_functions is 100.
Isn't it better to document this information so that users can understand not
all backtrace always can be logged? Patch attached.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Researc
On 2022/02/02 16:20, Peter Eisentraut wrote:
On 01.02.22 18:04, Fujii Masao wrote:
The maximum number of backtrace frames logged by backtrace_functions is 100.
Isn't it better to document this information so that users can understand not
all backtrace always can be logged? Patch att
;nframes" useful enough to
include in the report?
Probably No because "nframes" is equal to "lengthof(buf)" in the case where
more than 100 frames are generated.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA
On 2022/02/04 9:48, Fujii Masao wrote:
On 2022/02/03 23:48, Tom Lane wrote:
Peter Eisentraut writes:
How about we issue a message when the backtrace is cut off. Then it's
immediately visible to the user, instead of hidden away somewhere in the
documentation. Something like
On 2022/02/08 1:12, Peter Eisentraut wrote:
This change looks good to me. There is also backtrace code in assert.c that
might want the same treatment.
Yeah, that's good idea! The attached patch also adds the same treatment into
assert.c.
Regards,
--
Fujii Masao
Advanced Comp
On 2022/02/18 16:07, Peter Eisentraut wrote:
On 07.02.22 17:42, Fujii Masao wrote:
On 2022/02/08 1:12, Peter Eisentraut wrote:
This change looks good to me. There is also backtrace code in assert.c that
might want the same treatment.
Yeah, that's good idea! The attached patch also
On 2022/02/18 19:59, Peter Eisentraut wrote:
On 18.02.22 09:24, Fujii Masao wrote:
Or even backtrace should be logged by write_stderr() so that it's written to
eventlog if necessary? I just wonder why backtrace_symbols_fd() is used only in
ExceptionalCondition().
Probably because i
-1.5.8.32.19.2.2.25.1.1.1
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONFrom 735f4f095516ac7b1d4d838aeada3acffb4ae036 Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Fri, 15 Jul 2022 22:19:58 +0900
Subject: [PATCH] Improve
the existing function table.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATIONFrom db55800943ec0df13f91fe0315a965cc95689273 Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Wed, 20 Jul 2022 13:30:58 +0900
Subject: [PATCH] docs
On 2022/07/20 16:26, Michael Paquier wrote:
On Wed, Jul 20, 2022 at 01:51:36PM +0900, Fujii Masao wrote:
Attached is the updated version of the patch. It separates the list
for GUC flags from the table entry for pg_settings_get_flags() and
adds the table for it at the bottom of the existing
On 2022/07/20 18:07, Alvaro Herrera wrote:
Hello
On 2022-Jul-20, Fujii Masao wrote:
Attached is the updated version of the patch. It separates the list
for GUC flags from the table entry for pg_settings_get_flags() and
adds the table for it at the bottom of the existing function table.
I
the default) means no limit. To create such a role, use CREATE ROLE
name CONNECTION LIMIT connlimit
LOGIN.
"To create such a role" sounds odd to me in this context. Instead, how about something
like "Specify connection limit upon role creation with CREATE ROLE name CONNECTION LI
summarization is enabled. Attached patch adds that clarification to
the documentation. Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From 1339bbb4096df0182913c19a6277a105a2f5bee8 Mon Sep 17 00:00:00 2001
From
On 2024/12/11 9:18, Michael Paquier wrote:
On Fri, Oct 18, 2024 at 02:25:15AM +0900, Fujii Masao wrote:
The documentation in wal.sgml explains that old WAL files cannot be
removed or recycled until they are archived (when WAL archiving is used)
or replicated (when using replication slots
On 2024/12/13 9:12, Michael Paquier wrote:
On Fri, Dec 13, 2024 at 12:08:06AM +0900, Fujii Masao wrote:
Yes, that sounds like a good idea. I've updated the patch accordingly.
LGTM.
Pushed. Thanks!
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Develo
arate index entries. But commit 04ff636cbce
split them into distinct parameters.
Patch attached.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From fada9d65dd5c177e43179bcd5cc2e57d36b5d831 Mon Sep 17 00:00:00 2001
From: Fujii
On 2025/04/24 23:30, Robert Treat wrote:
On Wed, Apr 23, 2025 at 2:54 AM Fujii Masao wrote:
Hi,
In config.sgml, the entries for max_replication_slots and
max_active_replication_origins include secondary index terms:
max_replication_slots configuration
parameter
in a
On 2025/05/23 23:46, Fujii Masao wrote:
On 2025/05/23 19:52, Kevin K Biju wrote:
Hi Fuiji,
I wasn't aware that support for exporting snapshots goes as far back as v10.
The change looks good.
Thanks for the review!
I've prepared two patches: one for v15 and later, and anoth
hough
they're covered. Likewise, the pg_class catalog section describes
what can update fields like reltuples, but omits these functions,
which also affect those fields.
So I'd like to propose adding these missing references to improve clarity.
Patch attached. Thought?
Regards,
--
Fujii
- snapshot export may suppress it with the
NOEXPORT_SNAPSHOT
+ Applications that do not require
+ snapshot export may suppress it with the SNAPSHOT
'nothing'
option.
Regards,
[1]
https://www.postgresql.org/message-id/CAMsr+YFjxv0T8Yi1Q=3tvdgviu2bm+fb_-xubtfx
objections, I'll go ahead and commit and back-patch the
patch
to all supported branches.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
From 97f85a60cef32a12a1232d3d5e161718728d872f Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Fri, 23 May 2025 10:18:04 +0900
Subject: [PATCH v1] doc: F
ached.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
From e6a023b56f790c9995463d75e6101e5eaf49e98b Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Wed, 18 Jun 2025 13:56:14 +0900
Subject: [PATCH v1] doc: Fix incorrect description of INCLUDING COMMENTS in
CREATE FOREIGN TABLE.
Commit 302cf157592
. Patch
attached.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
From 649b27e536194589c2bf85a05cb84e731dbfeac0 Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Wed, 18 Jun 2025 16:30:36 +0900
Subject: [PATCH v1] doc: Mention GIN indexes support parallel builds.
Commit 8492feb98f6 added
On 2025/06/18 15:50, Michael Paquier wrote:
On Wed, Jun 18, 2025 at 02:34:55PM +0900, Fujii Masao wrote:
Commit 302cf157592 added support for LIKE in CREATE FOREIGN TABLE.
In this feature, since indexes are not created for foreign tables,
comments on indexes are not copied either.
Good
On 2025/06/18 16:55, Fujii Masao wrote:
On 2025/06/18 15:50, Michael Paquier wrote:
On Wed, Jun 18, 2025 at 02:34:55PM +0900, Fujii Masao wrote:
Commit 302cf157592 added support for LIKE in CREATE FOREIGN TABLE.
In this feature, since indexes are not created for foreign tables,
comments
On 2025/06/19 4:50, Robert Treat wrote:
On Wed, Jun 18, 2025 at 3:55 AM Fujii Masao wrote:
Hi,
Commit 8492feb98f6 added support for parallel CREATE INDEX on GIN indexes.
However, there are still two places in the docs and two in the source code
comments that mention only B-tree and BRIN
is "integer". This patch updates it
for consistency with other GUC parameter descriptions.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
From eee26a3c056e5c9951cc9c304c8a5b6ce4c44d9c Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Thu, 19 Jun 2025 17:52:58 +0900
Subject: [PAT
ct section. The attached patch
updates this accordingly.
Thoughts?
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
From e4fbb1929ccb43ff3adc282893167a2df6cbc1d2 Mon Sep 17 00:00:00 2001
From: Fujii Masao
Date: Fri, 20 Jun 2025 22:54:52 +0900
Subject: [PATCH v1] doc: Fix incorrect UUID index en
On 2025/06/19 19:34, Fujii Masao wrote:
Hi,
I'd like to propose three minor documentation fixes related to parameters
introduced in v18. Since they align with new content in that version,
I'm thinking to apply them to v18. Thoughts?
0001:
For parameters that exist as both configu
On 2025/06/25 0:28, Fujii Masao wrote:
On 2025/06/19 19:34, Fujii Masao wrote:
Hi,
I'd like to propose three minor documentation fixes related to parameters
introduced in v18. Since they align with new content in that version,
I'm thinking to apply them to v18. Thoughts?
On 2025/06/21 9:55, Masahiko Sawada wrote:
On Fri, Jun 20, 2025 at 11:33 PM Fujii Masao
wrote:
Hi,
Both the UUID data type and UUID functions pages define an index entry
for "UUID" that points to the data type section. As a result, the index
includes two identical entries link
umentation change to v13?
As for total_vacuum_time, since it's new in v18, I'd like to apply
the proposed change there.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
placement?
To make the documentation more intuitive and easier to navigate,
I suggest moving these entries after the SSL-related options.
Attached is a patch that does that.
Thanks,
--
Fujii Masao
NTT DATA Japan Corporation
From de4ba3e771840024f07b5132baddeeb1dd611709 Mon Sep 17 00:00:00 2001
From
On 2025/06/18 1:34, Jelte Fennema-Nio wrote:
On Tue, 17 Jun 2025 at 18:32, Fujii Masao wrote:
Hi,
Commit 285613c60a7 added the min_protocol_version and max_protocol_version
connection options to libpq. However, their descriptions currently appear
in the middle of the unrelated
On 2025/06/24 0:46, Fujii Masao wrote:
On 2025/06/23 23:52, Daniel Gustafsson wrote:
On 23 Jun 2025, at 16:40, Fujii Masao wrote:
So barring any objections, I will commit the patch.
+1, LGTM.
Thanks for the review!
There is one more occurrence though, the relnotes seem to need
On 2025/06/23 23:52, Daniel Gustafsson wrote:
On 23 Jun 2025, at 16:40, Fujii Masao wrote:
So barring any objections, I will commit the patch.
+1, LGTM.
Thanks for the review!
There is one more occurrence though, the relnotes seem to need the
same treatment as they talk about UUID
On 2025/06/07 0:13, Robert Treat wrote:
On Fri, Jun 6, 2025 at 9:57 AM David G. Johnston
wrote:
On Friday, June 6, 2025, Fujii Masao wrote:
Hi,
Since last_vacuum and vacuum_count in pg_stat_all_tables explicitly mention
that they don't include VACUUM FULL ("not counting VACUUM
t; but the required WALs have not been
dropped yet if the slot was invalidated due to the timeout. How about removing
the
first part:
```
lost means that this slot is no longer usable.
```
Agreed. Attached is the updated version of the patch.
Regards,
--
Fujii Masao
NTT DATA Japan Corpor
On 2025/06/26 15:46, Nisha Moond wrote:
On Wed, Jun 25, 2025 at 9:56 PM Fujii Masao wrote:
Hi,
The pg_replication_slots documentation mentions only max_slot_wal_keep_size
as a condition under which the wal_status column can show unreserved or lost.
However, since commit ac0e33136ab
1 - 100 of 119 matches
Mail list logo
