On Thu, 4 Sep 2025 13:50:41 +0100
Dean Rasheed wrote:
> On Thu, 28 Aug 2025 at 15:10, Yugo Nagata wrote:
> >
> > Thank you for your suggestion and the test patch. The test looks good
> > to me, so I’ve attached an updated patch including it.
>
> Thanks, that mostly l
machine-generated anyhow.
I also thought the O(N^2) behavior was acceptable, since it seemed unlikely
that users would try to create such a large number of enum labels.
If any complaints arise in the future, we can address them then.
Regards,
Yugo Nagata
--
Yugo Nagata
On Wed, 20 Aug 2025 14:10:28 +0900
Yugo Nagata wrote:
> On Fri, 8 Aug 2025 12:21:25 +0900
> Yugo Nagata wrote:
>
> > On Fri, 1 Aug 2025 00:28:30 +0900
> > Yugo Nagata wrote:
> >
> > > Hi,
> > >
> > > On Tue, 24 Jun 2025 17:05:33 +0900
constraints.
Regards,
Yugo Nagata
--
Yugo Nagata
diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml
index 874f3113ccb..75cf99b6390 100644
--- a/doc/src/sgml/release-18.sgml
+++ b/doc/src/sgml/release-18.sgml
@@ -1891,21 +1891,27 @@ Author: Thomas Munro
stions highlighted there:
1. Trigger-based Design: Should we avoid relying on triggers like declarative
partitioning?
2. Features Scope: Exclude aggregate, DISTINCT, and tuple duplicate supports
in the first release to simplify the patch and improve its reviewability?
3. Hidden Columns: How should they be handled?
4. Pre-update State of Table: Need infrastructure to scan a table using a
specified snapshot, instead of using the crafted sub-query?
5. Syntax: “CREATE INCREMENTAL MATERIALIZED VIEW” is tentative. Is
"CREATE MATERIALIZED VIEW … WITH (reloptions)" preferable?.
6. Other issues: EXPLAIN outputs, CONTEXT in an error message, etc.
In particular, I wonder whether it would be better to limit the scope of
the patch so that the proposal and discussion can move forward (#2).
This could help avoid some of the debates around aggregates support, hidden
columns, etc., and allow us to focus more on the core design.
Anyway, I will start rebasing the patches, reorganizing the patch set,
and applying fixes made in pg_ivm [2].
Regards,
Yugo Nagata
[1]
https://2025.pgconf.dev/static/posters/poster_incremental_view_maintenance.pdf
[2] https://github.com/sraoss/pg_ivm
--
Yugo Nagata
k for initial feedback on this proposal.
Regards,
Yugo Nagata
--
Yugo Nagata
>From a3f262cb96733cc041a7df1a43fe0f81c71f1474 Mon Sep 17 00:00:00 2001
From: Yugo Nagata
Date: Wed, 13 Aug 2025 19:16:06 +0900
Subject: [PATCH 2/2] pgbench: Add syntax for variable exisitence check
Now, :{?var}
On Wed, 27 Aug 2025 14:44:55 +0100
Dean Rasheed wrote:
> On Sun, 24 Aug 2025 at 18:34, Yugo Nagata wrote:
> >
> > I confirmed this issue by executing the following query concurrently
> > in three transactions. (With only two transactions, the issue does not
> >
ion,
> > > > > > and nothing is suggested after a comma.
> > > > > >
> > > > > > This patch enables suggestions after each comma, improving
> > > > > > usability when specifying
> > > > > > multiple options.
> > > > > >
> > > > > > Although not directly related to the main proposal, I believe this
> > > > > > is a helpful enhancement
> > > > > > to COPY tab completion and included it here for completeness.
> > > > > >
> > > > > > I’d appreciate your review and feedback on this series.
> Hi! This tab completion support is indeed very useful. Thanks for
> working on this.
Thank you for your feedback!
> I spotted potential improvement here: current v5 does not support COPY
> completion for a pattern I do frequently use:
> specifying COPY options without WITH clause e.g. "copy yy from
> '/home/reshke/cpg/csv.csv' " Is not completed with BINARY, CSV,
> DELIMITER etc.
This is the old syntax and is supported for backward compatibility
(commit 923413ac6d3), but I’m not sure it’s worth supporting in tab
completion. Perhaps it would be better to discuss this point in a
separate thread.
Regards,
Yugo Nagata
--
Yugo Nagata
Hi Jim,
On Mon, 25 Aug 2025 10:08:23 +0200
Jim Jones wrote:
> Hi Yugo
>
> On 03.07.25 17:04, Yugo Nagata wrote:
> > Currently, when creating an enum type, duplicate labels are caught by a
> > unique
> > index on pg_enum, resulting in a generic error message.
> &
On Mon, 25 Aug 2025 09:29:15 -0500
Nathan Bossart wrote:
> On Mon, Aug 25, 2025 at 10:30:32AM +0900, Yugo Nagata wrote:
> > The documentation fix looks good to me. However, it’s not very
> > user-friendly that,
> > when the user lacks the required privileges, an er
01 is the same as the previous.
The check is performed per database, so it may be a bit slower when an enormous
number of databases are processed, but the overhead should be relatively small
compared
with the other queries executed together.
Regards,
Yugo Nagata
--
Yugo Nagata
>From 7e86930e
tuple_lock in ExecMergeMatched().
Currently, TM_FailureData.ctid is used as a reference to the
latest version of oldtuple, but this is not always correct.
Instead, the tupleid passed to table_tuple_lock should be used.
I've attached a patch to fix this.
Regards,
Yugo Nagata
--
Yug
test and in the additional change
for inheritance tables. I had overlooked the latter one.
Regards,
Yugo Nagata
--
Yugo Nagata
On Thu, 17 Jul 2025 14:09:14 +0900
Yugo Nagata wrote:
> On Fri, 4 Jul 2025 14:58:05 +0900
> Yugo Nagata wrote:
>
> > On Fri, 4 Jul 2025 10:48:26 +0700
> > Daniil Davydov <3daniss...@gmail.com> wrote:
> >
> > > Hi,
> > >
>
On Fri, 8 Aug 2025 12:21:25 +0900
Yugo Nagata wrote:
> On Fri, 1 Aug 2025 00:28:30 +0900
> Yugo Nagata wrote:
>
> > Hi,
> >
> > On Tue, 24 Jun 2025 17:05:33 +0900
> > Yugo Nagata wrote:
> >
> > > Instead, I'm thinking of an alternative
On Wed, 20 Aug 2025 13:30:12 +0900
Yugo Nagata wrote:
> On Wed, 20 Aug 2025 12:49:14 +0900
> Fujii Masao wrote:
>
> > On Wed, Aug 20, 2025 at 10:42 AM Yugo Nagata wrote:
> > >
> > > Hi,
> > >
> > > I found that "vacuumdb --missing-st
On Wed, 20 Aug 2025 12:49:14 +0900
Fujii Masao wrote:
> On Wed, Aug 20, 2025 at 10:42 AM Yugo Nagata wrote:
> >
> > Hi,
> >
> > I found that "vacuumdb --missing-stats-only" always performs ANALYZE
> > on tables with a virtual generated column,
not
regarded as missing statistics.
Regards,
Yugo Nagata
--
Yugo Nagata
>From 21d05a07657969032a1ab3c3b8f84edfc8551b86 Mon Sep 17 00:00:00 2001
From: Yugo Nagata
Date: Wed, 20 Aug 2025 10:41:49 +0900
Subject: [PATCH] Don't treat virtual generated columns as missing statistics
in vacuum
On Fri, 1 Aug 2025 00:28:30 +0900
Yugo Nagata wrote:
> Hi,
>
> On Tue, 24 Jun 2025 17:05:33 +0900
> Yugo Nagata wrote:
>
> > Instead, I'm thinking of an alternative approach: expanding the expression
> > at the time statistics are collected.
>
> I
rated columns.
Regards,
Yugo Nagata
--
Yugo Nagata
>From 31fb12af49ed15b044b4d0c57f9a3fe37b1c1a72 Mon Sep 17 00:00:00 2001
From: Yugo Nagata
Date: Fri, 8 Aug 2025 11:34:11 +0900
Subject: [PATCH] Align tests for stored and virtual generated columns
These tests were intended to be aligned w
On Wed, 6 Aug 2025 13:20:18 +0900
Fujii Masao wrote:
> On Tue, Aug 5, 2025 at 10:09 AM Yugo Nagata wrote:
> > Thank you for looking at it. I overlooked that virtual generated columns
> > don't have statistics currently (I'm working on this at [1], though).
> >
On Mon, 4 Aug 2025 20:01:34 +0900
Fujii Masao wrote:
> On Mon, Aug 4, 2025 at 3:14 PM Yugo Nagata wrote:
> >
> > Hi,
> >
> > The documentation recommends running ANALYZE after the "ALTER TABLE ... SET
> > DATA TYPE"
> > command since the stat
he comment block.
That said, I'm not a native English speaker, so if no one else sees a problem,
I'm fine with it.
Regards,
Yugo Nagata
--
Yugo Nagata
, so I've attached a patch
to add this statement.
Regards,
Yugo Nagata
diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index 1e4f26c13f6..85c50428a13 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -270,6
Hi,
I found comments in do_analyze_rel that refers to "change_since_analyze".
I believe that is a typo and shoud be "mod_since_analyze".
I've attached a patch to fix it.
Regards,
Yugo Nagata
--
Yugo Nagata
diff --git a/src/backend/commands/analyze.c b/src/backend
On Fri, 1 Aug 2025 10:00:48 -0700
Masahiko Sawada wrote:
> On Fri, Aug 1, 2025 at 8:20 AM Yugo Nagata wrote:
> >
> > Hi,
> >
> > While reading autovacuum.c, I found the following comments in
> > AutoVacLauncherMain() right before the call to rebuild_database_
oker < current_time + autovacuum_naptime"
will always be true. Therefore, it seems redundant to explicitly check the
upper bound.
Am I missing something? I’d appreciate it if anyone could clarify this for me.
[1]
https://www.postgresql.org/message-id/20250802002027.cd35c481f6c6bae7ca2a3e26%40sraoss.co.jp
Regards,
Yugo Nagata
--
Yugo Nagata
as an
entry
However, I couldn't fnd any variable named "next_time". I believe it actually
refers
to adl_next_worker and the comments should use "next_worker" as is done in
other nereby
comments. I've attahed a patch to address this.
Regards,
Yugo Nagata
--
Yu
Hi,
On Tue, 24 Jun 2025 17:05:33 +0900
Yugo Nagata wrote:
> Instead, I'm thinking of an alternative approach: expanding the expression
> at the time statistics are collected.
I've attached a new patch in this approache.
This allows to collect statistics on virtual generated
On Tue, 22 Jul 2025 17:49:49 +0900
Yugo Nagata wrote:
> On Fri, 18 Jul 2025 17:07:53 +0900
> Rintaro Ikeda wrote:
>
> > Hi,
> >
> > On 2025/07/16 22:49, Yugo Nagata wrote:
> > >> I think we should also change the error message in pg_log_error. I
>
e person in charge of it, so I added the responsible email address
to the CC list.
Takatsuka-san, could you please take care of this?
Regards,
Yugo Nagata
--
Yugo Nagata
be very useful.
>
> Thoughts?
That seems reasonable to me.
Just one minor comment on the patch:
+
+
+
+ backup_type bigint
+
+
+Backup type. Either full or
+incremental.
+
+
The type should be text rather than bigint.
Regards,
Yugo Nagata
--
Yugo Nagata
On Fri, 18 Jul 2025 17:07:53 +0900
Rintaro Ikeda wrote:
> Hi,
>
> On 2025/07/16 22:49, Yugo Nagata wrote:
> >> I think we should also change the error message in pg_log_error. I
> >> modified the
> >> patch v8-0003 as follows:
> >> @@ -338
On Thu, 17 Jul 2025 10:57:36 +0900
Yugo Nagata wrote:
> On Tue, 17 Jun 2025 00:08:32 +0900
> Yugo Nagata wrote:
>
> > On Thu, 5 Jun 2025 16:52:00 +0900
> > Yugo Nagata wrote:
> >
> > > On Thu, 5 Jun 2025 10:08:35 +0900
> > > Yugo Nagata wrote:
On Fri, 4 Jul 2025 14:58:05 +0900
Yugo Nagata wrote:
> On Fri, 4 Jul 2025 10:48:26 +0700
> Daniil Davydov <3daniss...@gmail.com> wrote:
>
> > Hi,
> >
> > On Thu, Jul 3, 2025 at 9:18 PM Yugo Nagata wrote:
> > >
> > > On Tue, 1 Jul 2025 18:56:
On Tue, 17 Jun 2025 00:08:32 +0900
Yugo Nagata wrote:
> On Thu, 5 Jun 2025 16:52:00 +0900
> Yugo Nagata wrote:
>
> > On Thu, 5 Jun 2025 10:08:35 +0900
> > Yugo Nagata wrote:
> >
> > > Hi,
> > >
> > > Currently, tab completion for COP
On Wed, 16 Jul 2025 21:35:01 +0900
Rintaro Ikeda wrote:
> Hi,
>
> On 2025/07/15 11:16, Yugo Nagata wrote:
> >> I noticed one small thing I’d like to discuss. I'm not sure that users
> >> clearly
> >> understand which aborted in the following erro
; > fixing such a corner case. What do you think?
>
> I think it's worth doing. This issue can lead to unexpected behavior
> and is something users might run into. If the fix were overly complex
> for a minor issue, it might not be justified. But that's not the case here.
Thank you for your explanation.
It makes sense to me.
Regards,
Yugo Nagata
--
Yugo Nagata
nt that
was aborted.
I've attached an updated patch that replaces the remaining message mentioned
above with a call to commandFailed(). With this change, the output in such
situations will now be:
"client 0 aborted in command 0 (SQL) of script 0; "
Regards,
Yugo Nagata
--
Yugo N
h: error: client 0 aborted while executing SQL commands
I feel this is a bit redundant.
Therefore, if we are to improve these messages to indicate explicitly that the
client
was aborted, I would suggest modifying the error messages in
readCommandResponse() rather
than addi
On Thu, 10 Jul 2025 13:23:47 +0900
Fujii Masao wrote:
>
>
> On 2025/07/10 10:30, Yugo Nagata wrote:
> > You're right. I must have overlooked something. I think I saw "TO" being
> > suggested after "FOREIGN SERVER" when no foreign servers were defin
On Wed, 9 Jul 2025 20:42:42 +0900
Fujii Masao wrote:
>
>
> On 2025/06/11 13:57, Yugo Nagata wrote:
> > On Wed, 11 Jun 2025 13:33:07 +0900
> > Fujii Masao wrote:
> >
> >>
> >>
> >> On 2025/06/11 11:49, Yugo Nagata wrote:
> >>
>
> ```
>
> To confirm; --continue-on-error won't be counted here because it is not
> "retry",
> in other words, it does not reach CSTATE_RETRY, right?
Right. Transactions marked as failure due to --continue-on-error are not retried
and should not counted here.
Regards,
Yugo Nagata
--
Yugo Nagata
Hi,
On Tue, 1 Jul 2025 17:43:18 +0900
Rintaro Ikeda wrote:
> I've updated the previous patch based on your feedback. Below is a summary of
> the changes from v4 to v5:
Thank you for updating the patch.
> On 2025/06/14 0:24, Yugo Nagata wrote:
> > case
On Fri, 4 Jul 2025 10:48:26 +0700
Daniil Davydov <3daniss...@gmail.com> wrote:
> Hi,
>
> On Thu, Jul 3, 2025 at 9:18 PM Yugo Nagata wrote:
> >
> > On Tue, 1 Jul 2025 18:56:11 +0700
> > Daniil Davydov <3daniss...@gmail.com> wrote:
> >
> > >
a check for the label length here.
So I believe this is also the appropriate place to check for duplicates.
Regards,
Yugo Nagata
--
Yugo Nagata
On Thu, 3 Jul 2025 23:18:12 +0900
Yugo Nagata wrote:
> On Tue, 1 Jul 2025 18:56:11 +0700
> Daniil Davydov <3daniss...@gmail.com> wrote:
> > For example, with this patch such a query : "CREATE TYPE mood AS ENUM
> > ('happy', 'sad', 'happy&#x
LUE
or ALTER TYPE ... RENAME VALUE .. TO
With the attached patch applied, the error message becomes:
ERROR: label "a" used more than once
Regards,
Yugo Nagata
--
Yugo Nagata
>From 0b7f148e9ea6d9d6851e71f7ca3dc91b30b377af Mon Sep 17 00:00:00 2001
From: Yugo Nagata
Date: Thu, 3 J
On Tue, 1 Jul 2025 18:56:11 +0700
Daniil Davydov <3daniss...@gmail.com> wrote:
> Hi,
>
> On Tue, Jul 1, 2025 at 5:47 PM Yugo Nagata wrote:
> >
> > On Mon, 30 Jun 2025 18:32:47 +0700
> > Daniil Davydov <3daniss...@gmail.com> wrote:
> >
> > &
On Mon, 30 Jun 2025 18:32:47 +0700
Daniil Davydov <3daniss...@gmail.com> wrote:
> Hi,
>
> On Mon, Jun 30, 2025 at 3:47 PM Yugo Nagata wrote:
> >
> > On Fri, 27 Jun 2025 18:53:02 +0700
> > Daniil Davydov <3daniss...@gmail.com> wrote:
> > > This p
On Tue, 1 Jul 2025 13:29:44 +0900
Amit Langote wrote:
> On Tue, Jul 1, 2025 at 11:42 AM Amit Langote wrote:
> > Hi Nagata-san,
> >
> > On Tue, Jul 1, 2025 at 11:02 AM Yugo Nagata wrote:
> > >
> > > Hi,
> > >
> > > I found typos in the c
Hi,
I found typos in the comments of ExecInsertIndexTuples
that mention TUUI_{All, Summarizing} but they should be
TU_*.
I've attached a patch to fix it.
Regards,
Yugo Nagata
--
Yugo Nagata
diff --git a/src/backend/executor/execIndexing.c b/src/backend/executor/execIndexing.c
On Fri, 27 Jun 2025 18:53:02 +0700
Daniil Davydov <3daniss...@gmail.com> wrote:
> Hi,
>
> On Thu, Jun 5, 2025 at 5:21 PM Yugo Nagata wrote:
> >
> > I've attached updated patches.
> >
>
> I have some comments on v4-0001 patch :
Thank you for you
On Sat, 28 Jun 2025 00:33:45 +0900
Fujii Masao wrote:
>
>
> On 2025/06/27 13:09, Yugo Nagata wrote:
> > On Fri, 27 Jun 2025 12:22:17 +0900
> > Fujii Masao wrote:
> >
> >>> However, your patch is clear, and it seems we don't need to worry about
>
aint violation and is retried
with the same parameters, it will keep failing on each retry.
Regards,
Yugo Nagata
--
Yugo Nagata
On Mon, 26 May 2025 19:17:53 +1200
David Rowley wrote:
> On Mon, 26 May 2025 at 18:08, Yugo Nagata wrote:
> > While building PostgreSQL 17 on Windows, I noticed bitcode files (.bc) are
> > not
> > generated with meson. Does this means that "inlining" of JIT does
gt; Retrying the failed transaction is not necessary when the transaction
> failed due to SQL-level errors. Unlike real-world applications, pgbench
> does not need to complete specific transaction successfully. In the case
> of unique constraint violations, retrying the same transaction will
> likely to result in the same error again.
Agreed.
Regards,
Yugo Nagata
--
Yugo Nagata
e former is more appropriate, although the existing code uses the
latter. In any case, the error codes should be consistent.
Regarding the documentation, how about explicitly stating that when MATCH is
specified, only
the first line is skipped? While this may seem obvious, it’s worth clarifying,
as the semantics
of the HEADER option have become a bit more complex with this change.
Regards,
Yugo Nagata
--
Yugo Nagata
On Fri, 27 Jun 2025 01:45:16 +0900
Fujii Masao wrote:
>
>
> On 2025/06/27 1:31, Yugo Nagata wrote:
> > On Fri, 27 Jun 2025 01:05:47 +0900
> > Fujii Masao wrote:
> >
> >>
> >>
> >> On 2025/06/26 18:01, Yugo Nagata wrote:
> >>
On Fri, 27 Jun 2025 01:05:47 +0900
Fujii Masao wrote:
>
>
> On 2025/06/26 18:01, Yugo Nagata wrote:
> > Hi,
> >
> > The current documentation of pgbench’s \aset command states:
> >
> > “If a query returns no row, no assignment is made and the variab
retrying the transaction is very useful
> in this case.
You can use \aset command instead to avoid the error of pgbench. If the query
doesn't
return any row, a subsecuent SQL command trying to use the varialbe will fail,
but this
would be ignored without terminating the benchmark when the --coneinue-on-error
option
enabled.
> Anyway, we must confirm the opinion from the proposer.
+1
Best regards,
Yugo Nagata
--
Yugo Nagata
/message-id/flat/alpine.DEB.2.21.1904081914200.2529%40lancre
Best regards,
Yugo Nagata
--
Yugo Nagata
fix_doc_pgbench_aset.ptach
Description: Binary data
On Mon, 23 Jun 2025 09:56:19 +0200
Jelte Fennema-Nio wrote:
> On Mon, 23 Jun 2025 at 09:43, Andreas Lind
> wrote:
> >
> > Thanks for your replies!
> >
> > Tom Lane wrote:
> > > Yugo Nagata writes:
> > > > I'm not sure whether multi-t
On Tue, 17 Jun 2025 10:43:41 -0400
Andres Freund wrote:
> Hi,
>
> On 2025-04-22 18:10:06 +0900, Yugo Nagata wrote:
> > With your feedback, I would like to progress or rework the patch.
>
> Right now the tests seem to always fail:
> https://cirrus-ci.com/github/postgr
On Wed, 18 Jun 2025 11:12:48 +0900
Michael Paquier wrote:
> On Mon, Jun 16, 2025 at 10:37:43PM +0900, Yugo Nagata wrote:
> > I think it's a good idea to move the description of heap_create_with_catalog
> > directly above the function itself, as it seems better to keep
On Tue, 17 Jun 2025 16:28:28 +0900
Yugo Nagata wrote:
> On Tue, 17 Jun 2025 03:47:00 +
> "Hayato Kuroda (Fujitsu)" wrote:
>
> > Dear Nagata-san,
> >
> > > > > 2. The exit-on-abort option and continue-on-error option are mutually
> > >
certain network errors,
as this
would enable benchmarking with cluster systems or cloud services, which might
report
temporary errors during a failover. We would need additional work to properly
detect
and handle network errors, though.
However, I'm not sure it's reasonable to allow con
On Thu, 5 Jun 2025 16:52:00 +0900
Yugo Nagata wrote:
> On Thu, 5 Jun 2025 10:08:35 +0900
> Yugo Nagata wrote:
>
> > Hi,
> >
> > Currently, tab completion for COPY only suggests filenames after TO or
> > FROM, even though STDIN, STDOUT, and PROGRAM are also v
that were the case, I believe the impact of lacking LEAKPROOFness would
still depend more on how much each function can actually leak information,
rather
than on the roles accessing the data.
Therefore, if bypassing the LEAKPROOF check is allowed when RLS is enabled,
I think it would b
have a very minor comment on the initial patch.
+ * relrewrite: link to original relation during a table rewrite.
I wonder if the period at the end is unnecessary, since this is not a full
sentence, and for consistency with the other lines.
Best regards,
Yugo Nagata
> Regards,
> Steven
_file, st->command, qrynum,
PQerrorMessage(st->con));
goto error;
}
When an SQL error other than a serialization or deadlock error occurs, an error
message is
output via pg_log_error in this code path. However, I think this should be
reported only
when verbose_errors is set, similar to how serialization and deadlock errors
are handled when
--continue-on-error is enabled
Best regards,
Yugo Nagata
--
Yugo Nagata
On Wed, 11 Jun 2025 13:33:07 +0900
Fujii Masao wrote:
>
>
> On 2025/06/11 11:49, Yugo Nagata wrote:
> > While looking at the thread [1], I've remembered this thread.
> > The patches in this thread are partially v18-related, but include
> > enhancement or fixes
On Wed, 11 Jun 2025 13:33:07 +0900
Fujii Masao wrote:
>
>
> On 2025/06/11 11:49, Yugo Nagata wrote:
> > While looking at the thread [1], I've remembered this thread.
> > The patches in this thread are partially v18-related, but include
> > enhancement or fixes
On Tue, 8 Apr 2025 12:28:57 +0900
Yugo NAGATA wrote:
> On Fri, 4 Apr 2025 19:18:11 +0900
> Fujii Masao wrote:
>
> >
> >
> > On 2025/04/04 0:21, Fujii Masao wrote:
> > > Thanks for updating the patch!
> > >
> > > If there are no
On Tue, 10 Jun 2025 11:15:09 +0900
torikoshia wrote:
> On 2025-06-03 17:58, Yugo Nagata wrote:
> > Thank you for updating the patch.
> > It looks good and I confirmed that this works as expected.
>
> Thanks for your review!
>
> BTW this is a small patch, but it doe
On Thu, 5 Jun 2025 16:26:08 +0900
Yugo Nagata wrote:
> On Tue, 3 Jun 2025 17:39:50 +0900
> Yugo Nagata wrote:
>
> > On Tue, 27 May 2025 09:00:01 +0300
> > Alexander Lakhin wrote:
>
> > I know there are other scenarios where the same is raises and I agree
On Thu, 5 Jun 2025 10:08:35 +0900
Yugo Nagata wrote:
> Hi,
>
> Currently, tab completion for COPY only suggests filenames after TO or
> FROM, even though STDIN, STDOUT, and PROGRAM are also valid syntax options.
>
> I'd like to propose improving the tab completion b
On Tue, 3 Jun 2025 17:39:50 +0900
Yugo Nagata wrote:
> On Tue, 27 May 2025 09:00:01 +0300
> Alexander Lakhin wrote:
> I know there are other scenarios where the same is raises and I agree that
> it would be better to consider a more global solution instead of addressing
> each o
es.
Best regards,
Yugo Nagata
--
Yugo Nagata
>From 10e3ffa305e5a318b4a3ea8cbe8e36cea085e4d7 Mon Sep 17 00:00:00 2001
From: Yugo Nagata
Date: Thu, 5 Jun 2025 09:39:09 +0900
Subject: [PATCH 3/3] Improve tab completion for COPY option lists
Previously, only the first option in a parenthes
On Thu, 8 May 2025 21:39:10 +0900
torikoshia wrote:
> Thanks for your comments!
>
> On 2025-05-08 08:53, Yugo Nagata wrote:
> > On Wed, 7 May 2025 14:36:35 -0700
> > Masahiko Sawada wrote:
> >
> >> On Wed, May 7, 2025 at 6:23 AM Yugo Nagata
> >>
On Tue, 27 May 2025 09:00:01 +0300
Alexander Lakhin wrote:
> Hello Yugo,
>
> 31.03.2025 14:22, Yugo Nagata wrote:
> >> I found that multiple sessions concurrently execute CREATE OR REPLACE
> >> FUNCTION
> >> for a same function, the error "tuple concu
On Wed, 28 May 2025 23:14:36 +0900
Yugo Nagata wrote:
> On Thu, 1 May 2025 22:44:50 -0400
> Bruce Momjian wrote:
>
> > I have committd the first draft of the PG 18 release notes. The item
> > count looks strong:
>
> Some items in the "EXPLAIN" section are
to the
"Utility Commands" section with a little edit of wordings.
Regards,
Yugo Nagata
--
Yugo Nagata
diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml
index 2ae03065f94..0008c9a9f75 100644
--- a/doc/src/sgml/release-18.sgml
+++ b/doc/src/sgml/release-18.sgml
@@ -
On Tue, 27 May 2025 08:33:42 +0200
Jim Jones wrote:
> Hi Yugo
>
> On 26.05.25 18:39, Yugo Nagata wrote:
> > I can see the error when two concurrent transactions issue
> > "alter function f() immutable".
>
>
> I might have missed something in my l
On Tue, 27 May 2025 10:03:58 +0800
jian he wrote:
> On Tue, May 27, 2025 at 1:35 AM Yugo Nagata wrote:
> >
> > > + /* Lock the function so nobody else can do anything with it. */
> > > + LockDatabaseObject(ProcedureRelationId, oldproc->oid,
sValid. I've attached a updated patch.
Regards,
Yugo Nagata
--
Yugo Nagata
>From b5b79dffb96760b47632cc9d325a034f5cc020e9 Mon Sep 17 00:00:00 2001
From: Yugo Nagata
Date: Mon, 31 Mar 2025 20:17:07 +0900
Subject: [PATCH v2 2/2] Prevent internal error at concurrent ALTER FUNCTION
---
laces[Anum_pg_proc_proacl - 1] = false;
>
> +
> +
> /* Okay, do it... */
> no need to add these two new lines.
I'll remove the lines. Thanks.
Regards,
Yugo Nagata
--
Yugo Nagata
d. Could you provide your script?
I can see the error when two concurrent transactions issue
"alter function f() immutable".
Regards,
Yugo Nagata
--
Yugo Nagata
Hi,
The attached partch is fix the following typo.
-additionally an index is over these is stored to
+additionally an index over these is stored to
Regards,
Yugo Nagata
--
Yugo Nagata
diff --git a/src/backend/jit/README b/src/backend/jit/README
index 5427bdf2153..a40950dfb03 100644
--- a/src
ntation so that users and packagers would except JIT doesn't work in the
same
way when built with meson and autoconf/make?
Regards,
Yugo Nagata
--
Yugo Nagata
On Wed, 7 May 2025 14:36:35 -0700
Masahiko Sawada wrote:
> On Wed, May 7, 2025 at 6:23 AM Yugo Nagata wrote:
> >
> > On Wed, 7 May 2025 15:39:26 +0900
> > torikoshia wrote:
> >
> > > Hi,
> > >
> > > I noticed that REJECT_LIMIT, an
ontaining common options part, then appending options
specific to each mode using some function like kind of append_variable_names,
and passing these lists to COMPLETE_WITH_LIST.
Regards,
Yugo Nagata
> Attached patch splits the tab completion rules between COPY FROM and
> COPY TO, so that only
On Thu, 1 May 2025 22:44:50 -0400
Bruce Momjian wrote:
> I have committd the first draft of the PG 18 release notes. The item
> count looks strong:
Thank you for working on this.
> Have pgbench report the number of failed transactions (Yugo Nagata)
I think that should be
&quo
rework the patch.
Regards,
Yugo Nagata
--
Yugo Nagata
>From a6b0be714f6d4e4e0e7423f07432d3135c807a63 Mon Sep 17 00:00:00 2001
From: Yugo Nagata
Date: Tue, 22 Apr 2025 17:03:50 +0900
Subject: [PATCH v1] Allow to create extended statistics on virtual generated
columns
---
src/backend/command
or the
"FOREIGN SERVER", server names should be suggested ratar than TO/FROM
in this case.
The additional patch 0002 fixed to prevents to suggest TO or FROM right
after LARGE OBJECT or FOREIGN SERVER. Also, it allows to suggest list of
foreign server names aft
epting
connections"),
+ errdetail("Recovery snapshot is not yet ready for
hot standby."),
+errhint("To enable hot standby, close write
transactions with more than %d subtransactions on the primary server.",
+PGPROC_MAX_CACHED_SUBXIDS)));
else
ereport(FATAL,
(errcode(ERRCODE_CANNOT_CONNECT_NOW),
errmsg("the database system is not accepting
connections"),
-errdetail("Hot standby mode is disabled.")));
+errdetail("Consistent recovery state has not been
yet reached.")));
The message says "the database system is not yet accepting connections" when
"Hot standby mode is disabled".
I think "yet" is not necessary in this case. Otherwise, when "Recovery snapshot
is not yet ready for hot standby"
or "Consistent recovery state has not been yet reached", it seems better to use
"yet"
Regards,
Yugo Nagata
--
Yugo Nagata
ternal error by locking an exclusive
lock before the command and get the read tuple after acquiring the lock.
Also, if the function has been removed during the lock waiting, the new entry
is created.
Regards,
Yugo Nagata
--
Yugo Nagata
>From 49c890eb8cb115586e0e92294fb2fec60d80b8be Mon Sep 17
On Wed, 2 Apr 2025 02:35:35 +0900
Fujii Masao wrote:
>
>
> On 2025/01/23 19:22, Yugo NAGATA wrote:
> > On Wed, 22 Jan 2025 13:30:17 +0100
> > Laurenz Albe wrote:
> >
> >> On Fri, 2024-09-13 at 16:18 +0900, Yugo Nagata wrote:
> >>> I've
On Mon, 31 Mar 2025 20:00:57 +0900
Yugo Nagata wrote:
> Hi,
>
> I found that multiple sessions concurrently execute CREATE OR REPLACE FUNCTION
> for a same function, the error "tuple concurrently updated" is raised. This is
> an internal error output by elog, als
//www.postgresql.org/message-id/flat/20250331200057.00a62760966a821d484ea904%40sraoss.co.jp
--
Yugo Nagata
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 6e433db039e..f47b878f559 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap
1 - 100 of 671 matches
Mail list logo
