On Wed, 14 Feb 2024 07:21:54 +0900
Michael Paquier wrote:
> On Tue, Feb 13, 2024 at 11:23:47PM +0800, Julien Rouhaud wrote:
> > +1!
>
> Okay, applied as-is, then.
Thank you!
Regards,
Yugo Nagata
> --
> Michael
--
Yugo NAGATA
On Sat, 10 Feb 2024 10:19:15 +0900
Michael Paquier wrote:
> On Fri, Feb 09, 2024 at 04:37:23PM +0800, Julien Rouhaud wrote:
> > On Fri, Feb 09, 2024 at 03:38:23PM +0900, Yugo NAGATA wrote:
> >> Also, I think the name is a bit confusing for the same reason, that is,
> >&
function.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/nodes/queryjumblefuncs.c b/src/backend/nodes/queryjumblefuncs.c
index e489bfceb5..e4fbcf0d9f 100644
--- a/src/backend/nodes/queryjumblefuncs.c
+++ b/src/backend/nodes/queryjumblefuncs.c
@@ -42,8 +42,8 @@
/* GUC parameters */
int
On Wed, 7 Feb 2024 22:59:48 +0100
Daniel Gustafsson wrote:
> > On 1 Feb 2024, at 02:21, Yugo NAGATA wrote:
> > On Tue, 30 Jan 2024 13:44:28 +0100
> > Daniel Gustafsson wrote:
>
> >> -setup_cancel_handler(void)
> >> +pg_dump_setup_cancel_handler(v
On Wed, 24 Jan 2024 22:17:44 +0900
Yugo NAGATA wrote:
> Attached is the updated patch, v6.
Currently, on non-Windows, SIGINT is received only by thread #0.
CancelRequested is checked during the loop in the thread, and
queries are cancelled if it is set. However, once thread #0 exits
the l
s too strong because it is very
common that a table has a primary key, unless there is some way
to specify columns that can be set to NULL. Even when ON_ERROR
is specified, any constraint violation errors cannot be generally
ignored, so we cannot elimiate the posibility COPY FROM fails in
the middle due to invalid data, anyway.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Tue, 06 Feb 2024 09:39:09 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Mon, 5 Feb 2024 17:22:56 +0900, Yugo NAGATA wrote in
> > On Mon, 05 Feb 2024 11:28:59 +0900
> > torikoshia wrote:
> >
> > > > Based on this, I've made a patch.
> > > &
so I suggested to use
"set_to_null" or more generic syntax like "set_to (col, val)" in my
previous post[1], although I'm not convinced what is the best either.
[1]
https://www.postgresql.org/message-id/20240129172858.ccb6c77c3be95a295e2b2b44%40sraoss.co.jp
Regards,
Yugo Nagata
--
Yugo NAGATA
On Thu, 1 Feb 2024 17:59:56 +0800
jian he wrote:
> On Thu, Feb 1, 2024 at 12:45 PM Yugo NAGATA wrote:
> >
> > Here is a updated patch, v6.
>
> v6 patch looks good.
Thank you for your review and updating the status to RwC!
Regards,
Yugo Nagata
--
Yugo NAGATA
On Sat, 3 Feb 2024 01:51:56 +0200
Alexander Korotkov wrote:
> On Fri, Feb 2, 2024 at 10:07 PM David G. Johnston
> wrote:
> > On Thu, Feb 1, 2024 at 11:59 PM Yugo NAGATA wrote:
> >>
> >>
> >> I attached a updated patch including fixes you pointed out above
I can't see any existing defences.
>
> One simple way to address that would be to make XLogFileInitInternal()
> wait for InstallXLogFileSegment() to finish. It's a little
Or, can we make sure the rename is durable by calling fsync before
returning the fd, as a patch attached her
t;
> I've attached a patch to fix it in case this is a typo.
I also think it should be ">="
Also, if so, I don't think the check of MINIMUM_VERSION_FOR_PG_WAL
in the block is required, because the directory name is always pg_wal
in the new versions.
Regards,
Yugo Nagata
>
> --
> Artur
--
Yugo NAGATA
On Fri, 02 Feb 2024 11:29:41 +0900
torikoshia wrote:
> On 2024-02-01 15:16, Yugo NAGATA wrote:
> > On Mon, 29 Jan 2024 15:47:25 +0900
> > Yugo NAGATA wrote:
> >
> >> On Sun, 28 Jan 2024 19:14:58 -0700
> >> "David G. Johnston" wrote:
> >&g
On Mon, 29 Jan 2024 15:47:25 +0900
Yugo NAGATA wrote:
> On Sun, 28 Jan 2024 19:14:58 -0700
> "David G. Johnston" wrote:
>
> > > Also, I think "invalid input syntax" is a bit ambiguous. For example,
> > > COPY FROM raises an error when the num
On Tue, 30 Jan 2024 14:57:20 +0800
jian he wrote:
> On Tue, Jan 30, 2024 at 1:56 PM Yugo NAGATA wrote:
> >
> > I attached the correct one, v4.
> >
>
> +-- Test pg_column_toast_chunk_id:
> +-- Check if the returned chunk_id exists in the TOAST table
> +CREATE
On Tue, 30 Jan 2024 13:44:28 +0100
Daniel Gustafsson wrote:
> > On 26 Jan 2024, at 01:42, Yugo NAGATA wrote:
>
> > I am proposing it because there is a public function with
> > the same name in fe_utils/cancel.c. I know pg_dump/parallel.c
> > does not include fe_uti
On Tue, 30 Jan 2024 13:47:45 +0800
jian he wrote:
> On Tue, Jan 30, 2024 at 12:35 PM Yugo NAGATA wrote:
> >
> >
> > Sorry, I also attached a wrong file.
> > Attached is the correct one.
> I think you attached the wrong file again. also please name it as v4.
Opps
On Tue, 30 Jan 2024 12:12:31 +0800
jian he wrote:
> On Fri, Jan 26, 2024 at 8:42 AM Yugo NAGATA wrote:
> >
> > On Tue, 2 Jan 2024 08:00:00 +0800
> > jian he wrote:
> >
> > > On Mon, Nov 6, 2023 at 8:00 AM jian he
> > > wrote:
> > > >
soft error, although the syntax would be a bit complex...)
IMO, it is more simple to define "ignore" as to skip the entire row rather
than having variety of "ignore". Once defined it so, the option to set the
column value to NULL should not be called "ignore" because values in other
columns will be inserted.
Regards,
Yugo Nagata
>
> David J.
--
Yugo NAGATA
rstand “as if you deleted it” as their operational concept more
> readily than visible. I think this will be read by people who haven’t read
> MVCC to fully understand what visible means but know enough to run vacuum
> to clean up updated and deleted data as a rule.
Ok, I agree we can omit "or accessible". How do you like the followings?
Still redundant?
"If the command fails, these rows are left in a deleted state;
these rows will not be visible, but they still occupy disk space. "
Regards,
Yugo Nagata
--
Yugo NAGATA
On Fri, 26 Jan 2024 08:04:45 -0700
"David G. Johnston" wrote:
> On Fri, Jan 26, 2024 at 2:30 AM Yugo NAGATA wrote:
>
> > On Fri, 26 Jan 2024 00:00:57 -0700
> > "David G. Johnston" wrote:
> >
> > > I will need to make this tweak and proba
On Fri, 26 Jan 2024 00:00:57 -0700
"David G. Johnston" wrote:
> On Thursday, January 25, 2024, Yugo NAGATA wrote:
>
> >
> > Maybe, we can separate the sentese to two, for example:
> >
> > COPY stops operation at the first error. (The exception i
On Thu, 25 Jan 2024 23:33:22 -0700
"David G. Johnston" wrote:
> On Thu, Jan 25, 2024 at 10:40 PM Yugo NAGATA wrote:
>
> > On Fri, 26 Jan 2024 13:59:09 +0900
> > Masahiko Sawada wrote:
> >
> > > On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA
>
On Fri, 26 Jan 2024 15:26:55 +0900
Masahiko Sawada wrote:
> On Fri, Jan 26, 2024 at 2:40 PM Yugo NAGATA wrote:
> >
> > On Fri, 26 Jan 2024 13:59:09 +0900
> > Masahiko Sawada wrote:
> >
> > > On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA wrote:
> > &g
On Fri, 26 Jan 2024 13:59:09 +0900
Masahiko Sawada wrote:
> On Fri, Jan 26, 2024 at 11:28 AM Yugo NAGATA wrote:
> >
> > Hi,
> >
> > I found that the documentation of COPY ON_ERROR said
> > COPY stops operation at the first error when
> > "ON_ERR
iption more accurate.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/doc/src/sgml/ref/copy.sgml b/doc/src/sgml/ref/copy.sgml
index 21a5c4a052..14c8ceab06 100644
--- a/doc/src/sgml/ref/copy.sgml
+++ b/doc/src/sgml/ref/copy.sgml
@@ -577,8 +577,8 @@ COPY count
COPY stops operation at
introduced in a4fd3aa719e, where this function
was moved from psql.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/bin/pg_dump/parallel.c b/src/bin/pg_dump/parallel.c
index 188186829c..261b23cb3f 100644
--- a/src/bin/pg_dump/parallel.c
+++ b/src/bin/pg_dump/parallel.c
@@ -204,7 +204,7
Size
> Functions).
I could not find any change in your patch from my previous patch.
Maybe, you attached wrong file. I attached a patch updated based
on your review, including the documentation fixes and a test.
What do you think about this it?
Regards,
Yugo Nagata
--
Yugo NAGATA
>From
* required because all threads running queries continue to run without
+* interrupted even when the signal is received.
+ *
Attached is the updated patch, v6.
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.
40mail.gmail.com
Regards,
Yugo Nagata
> ==
> [1] https://commitfest.postgresql.org/46/4337/
> [2] https://cirrus-ci.com/task/6607979311529984
>
> Kind Regards,
> Peter Smith.
--
Yugo NAGATA
On Mon, 15 Jan 2024 16:49:44 +0900 (JST)
Tatsuo Ishii wrote:
> > On Wed, 6 Sep 2023 20:13:34 +0900
> > Yugo NAGATA wrote:
> >
> >> I attached the updated patch v3. The changes since the previous
> >> patch includes the following;
> >>
> >&g
pport for access to regular tables is ".
Ragards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/doc/src/sgml/xindex.sgml b/doc/src/sgml/xindex.sgml
index c753d8005a..ff73233818 100644
--- a/doc/src/sgml/xindex.sgml
+++ b/doc/src/sgml/xindex.sgml
@@ -30,11 +30,8 @@
The pg_am table co
On Tue, 26 Sep 2023 08:18:01 +0900
Michael Paquier wrote:
> On Mon, Sep 25, 2023 at 11:07:57AM -0400, Andrew Dunstan wrote:
> > +1
>
> Thanks, applied and backpatched then.
Thank you!
Regards,
Yugo Nagata
> --
> Michael
--
Yugo NAGATA
ge-id/flat/ZQzp_VMJcerM1Cs_%40paquier.xyz
I attached a patch for this case.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/doc/src/sgml/install-windows.sgml b/doc/src/sgml/install-windows.sgml
index 379a2ea80b..435a91228a 100644
--- a/doc/src/sgml/install-windows.sgml
+++ b/doc/src/sgml/install-windows.sgml
On Wed, 6 Sep 2023 20:13:34 +0900
Yugo NAGATA wrote:
> I attached the updated patch v3. The changes since the previous
> patch includes the following;
>
> I removed the unnecessary condition (&& false) that you
> pointed out in [1].
>
> The test was rewritten b
On Wed, 13 Sep 2023 10:20:23 +0900
Michael Paquier wrote:
> On Tue, Sep 12, 2023 at 03:18:05PM +0900, Michael Paquier wrote:
> > On Wed, Sep 06, 2023 at 12:45:24AM +0900, Yugo NAGATA wrote:
> > > I attached the update patch. I removed the incorrect comments and
> > >
On Thu, 7 Sep 2023 13:06:35 +0200
Alvaro Herrera wrote:
> On 2023-Sep-07, Yugo NAGATA wrote:
>
> > Yes. So, I mean how about fixing \watch description as the attached patch.
>
> > diff --git a/src/bin/psql/help.c b/src/bin/psql/help.c
> > index 38c165a627..12280c0e
On Thu, 07 Sep 2023 15:36:10 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Thu, 7 Sep 2023 15:02:49 +0900, Yugo NAGATA wrote in
> > On Thu, 07 Sep 2023 14:29:56 +0900 (JST)
> > Kyotaro Horiguchi wrote:
> > > > \q quit psql
> > &g
this.
I wonder this better to fix this in similar way to other places where the
description has multiple lines., like "\g [(OPTIONS)] [FILE]".
Regards,
Yugo Nagata
>
> [1]
> https://www.postgresql.org/message-id/20230830.103356.1909699532104167477.horikyota....@gmail.com
>
> regards.
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
--
Yugo NAGATA
Hi Fabien,
On Thu, 10 Aug 2023 12:32:44 +0900
Yugo NAGATA wrote:
> On Wed, 9 Aug 2023 11:18:43 +0200 (CEST)
> Fabien COELHO wrote:
>
> >
> > I forgot, about the test:
> >
> > I think that it should be integrated in the existing
> > "001_pgbench_
On Mon, 14 Aug 2023 23:37:25 +0900
Yugo NAGATA wrote:
> On Mon, 14 Aug 2023 08:29:25 +0900
> Michael Paquier wrote:
>
> > On Sun, Aug 13, 2023 at 11:22:33AM +0200, Fabien COELHO wrote:
> > > Test run is ok on my Ubuntu laptop.
> >
> > I have a few comment
t; >>> Without
> >>>
> >>> (error vs. erros)
> >>
> >> Well, I chose "some" to mean "unknown or unspecified", not "an unspecified
> >> amount
> >> or number of", so singular form "error" is used.
> >
> > Ok.
> >
> >> Instead, should we use "due to a error"?
> >
> > I don't think so.
> >
> >>> Also:
> >>> + --exit-on-abort is specified . Otherwise in
> >>> the worst
> >>>
> >>> There is an extra space between "specified" and ".".
> >>
> >> Fixed.
> >>
> >> Also, I fixed the place of the description in the documentation
> >> to alphabetical order
> >>
> >> Attached is the updated patch.
> >
> > Looks good to me. If there's no objection, I will commit this next week.
>
> I have pushed the patch. Thank you for the conributions!
Thank you!
Regards,
Yugo Nagata
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
--
Yugo NAGATA
uple_count(new_tuplestores) to 1, it will walk through
> IVM_immediate_maintenance function to apply_delta.
> but should it be zero?
This is not a bug because an aggregate without GROUP BY always
results one row whose value is NULL.
The contents of test_imv1 would be always same as " SELECT MIN(j) as mi
SELECT %s FROM %s AS diff "
>
> the INSERT INTO line, should have one white space in the end?
> also "existw" should be "exists"
Yes, we should need a space although it works. I'll fix as well as the typo.
Thank you.
Regards,
Yugo Nagata
--
Yugo NAGATA
+" command for an
incrementally maintained materialized view.
Regards,
Yugo Nagata
--
Yugo NAGATA
m']
> error: file doc/src/sgml/postgres-full.xml
> xsltRunStylesheet : run failed
> ninja: build stopped: subcommand failed.
Thank your for pointing out this.
I'll add ids for all sections to suppress the errors.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Thu, 29 Jun 2023 18:20:32 +0800
jian he wrote:
> On Thu, Jun 29, 2023 at 12:40 AM jian he wrote:
> >
> > On Wed, Jun 28, 2023 at 4:06 PM Yugo NAGATA wrote:
> > >
> > > On Wed, 28 Jun 2023 00:01:02 +0800
> > > jian he wrote:
> > >
> &
On Thu, 29 Jun 2023 00:40:45 +0800
jian he wrote:
> On Wed, Jun 28, 2023 at 4:06 PM Yugo NAGATA wrote:
> >
> > On Wed, 28 Jun 2023 00:01:02 +0800
> > jian he wrote:
> >
> > > On Thu, Jun 1, 2023 at 2:47 AM Yugo NAGATA wrote:
> > > >
> &
; > or number of", so singular form "error" is used.
>
> Ok.
>
> > Instead, should we use "due to a error"?
>
> I don't think so.
>
> >> Also:
> >> + --exit-on-abort is specified . Otherwise in the
> >> wor
, I chose "some" to mean "unknown or unspecified", not "an unspecified
amount
or number of", so singular form "error" is used.
Instead, should we use "due to a error"?
> Also:
> + --exit-on-abort is specified . Otherwise in the
>
a
> # file.
>
> This is also incorrect.
Thank you for your comments
I will check whether the test works in Windows and remove SKIP if possible.
Also, I'll fix the comment in either case.
Regards,
Yugo Nagata
--
Yugo NAGATA
warnings...
>
> Compiles. Code is ok. Tests are ok.
>
> About Test:
>
> The code is simple to get an error quickly but after a few transactions,
> good. I'll do a minimal "-c 2 -j 2 -t 10" instead of "-c 4 -j 4 -T 10".
I fixed the test and attach
4-e26-135ccfbf0e9%40mines-paristech.fr
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/bin/psql/t/020_cancel.pl b/src/bin/psql/t/020_cancel.pl
index 0765d82b92..081a1468d9 100644
--- a/src/bin/psql/t/020_cancel.pl
+++ b/src/bin/psql/t/020_cancel.pl
@@ -29,35 +29,10 @@ SKIP:
my
ld be simplified to use that after a small delay.
Thank you for your information.
I didn't know $h->signal() and I mimicked the way of
src/bin/psql/t/020_cancel.pl to send SIGINT to a running program. I don't
know why the psql test doesn't use the interface, I'll investiga
may also be stuck waiting for events so the cancel is only
> taken into account when it is woken up.
I answered to (1) the consern about race condition above.
And, as to (2), the SIGINT signal is handle only in thread #0 because it is
blocked in other threads. So, when SIGINT is delivered, th
On Wed, 9 Aug 2023 13:59:21 +0900
Yugo NAGATA wrote:
> On Wed, 9 Aug 2023 10:46:38 +0900
> Yugo NAGATA wrote:
>
> > On Wed, 9 Aug 2023 02:15:01 +0200 (CEST)
> > Fabien COELHO wrote:
> >
> > >
> > > Hello Yugo-san,
> > >
> > &g
On Wed, 9 Aug 2023 10:46:38 +0900
Yugo NAGATA wrote:
> On Wed, 9 Aug 2023 02:15:01 +0200 (CEST)
> Fabien COELHO wrote:
>
> >
> > Hello Yugo-san,
> >
> > > There are cases where "goto done" is used where some error like
> > > "invali
checking loop *before* the
> disconnect_all, and the overall section comment could be something like
> "possibly abort if any client is not finished, meaning some error
> occured", which is consistent with the "!= FINISHED" condition.
Thank you for your suggestion.
I'll fix as above and submit a updated patch soon.
Regards,
Yugo Nagata
--
Yugo NAGATA
ove) after
skipping to "done", we should set the status to CSTATE_ABORTED before the jump.
Otherwise, if we choose to call "exit" immediately at each error instead of
skipping to "done", we can remove this as you says.
> Typo: "going to exist" -> "going to exit". Note that it is not "the whole
> thread" but "the program" which is exiting.
I'll fix.
> There is no test.
I'll add an test.
Regards,
Yugo Nagata
> --
> Fabien.
--
Yugo NAGATA
On Mon, 7 Aug 2023 11:02:48 +0900
Yugo NAGATA wrote:
> On Sat, 05 Aug 2023 12:16:11 +0900 (JST)
> Tatsuo Ishii wrote:
>
> > > Hi,
> > >
> > > I would like to propose to add an option to pgbench so that benchmark
> > > can quit immediately
pose.
In order to stop pgbench more gracefully, it might be better to make
each thread exit at more proper timing after some cleaning-up like
connection close. However, pgbench code doesn't provide such functions
for inter-threads communication. If we would try to make this, both
pthread an
hat do you think about it?
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 539c2795e2..6fae5a43e1 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -765,6 +765,8 @@ static int64 total_weight = 0;
s
On Wed, 2 Aug 2023 16:37:53 +0900
Yugo NAGATA wrote:
> Hello Fabien,
>
> On Fri, 14 Jul 2023 20:32:01 +0900
> Yugo NAGATA wrote:
>
> I attached the updated patch.
I'm sorry. I forgot to attach the patch.
Regards,
Yugo Nagata
>
> > Hello Fabien,
&g
Hello Fabien,
On Fri, 14 Jul 2023 20:32:01 +0900
Yugo NAGATA wrote:
I attached the updated patch.
> Hello Fabien,
>
> Thank you for your review!
>
> On Mon, 3 Jul 2023 20:39:23 +0200 (CEST)
> Fabien COELHO wrote:
>
> >
> > Yugo-san,
> >
&
s in simpler way.
In my patch, all threads can return from wait_on_socket_set at Ctrl+C
because when thread #0 cancels all connections, the following error is
sent to all sessions:
ERROR: canceling statement due to user request
and all threads will receive the response from the backend.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Fri, 7 Jul 2023 17:21:36 +0900
Yugo NAGATA wrote:
> Hi Nikita,
>
> On Wed, 5 Jul 2023 17:49:20 +0300
> Nikita Malakhov wrote:
>
> > Hi!
> >
> > I like the idea of having a standard function which shows a TOAST value ID
> > for a row. I've use
g/docs/devel/storage-toast.html
Here, chunk_id defined separately from chunk_seq. Therefore, I wonder
pg_column_toast_chunk_id would be ok. However, I don't insist on this
and I would be happy to change it if the other name is more natural for users.
Regards,
Yugo Nagata
>
> --
> R
On Wed, 28 Jun 2023 00:01:02 +0800
jian he wrote:
> On Thu, Jun 1, 2023 at 2:47 AM Yugo NAGATA wrote:
> >
> > On Thu, 1 Jun 2023 23:59:09 +0900
> > Yugo NAGATA wrote:
> >
> > > Hello hackers,
> > >
> > > Here's a rebased version
In this case,
I wonder we should follow SQL:1999 or later, and maybe this would be somehow
compatible to the spec in Oracle.
[1] https://dl.acm.org/doi/10.1145/3164541.3164584
[2] https://www.pgcon.org/2017/schedule/events/1074.en.html
Regards,
Yugo Nagata
> Yours
> Terry Brennan
--
Yugo NAGATA
On Mon, 26 Jun 2023 12:59:21 -0400
Kirk Wolak wrote:
> On Mon, Jun 26, 2023 at 9:46 AM Yugo NAGATA wrote:
>
> > Hello,
> >
> > This attached patch enables pgbench to cancel queries during benchmark.
> >
> > Formerly, Ctrl+C during benchmark killed pgbench im
hat catches the signal is
responsible to sent cancel requests for all connections may also work.
Also, the array of CState that contains all clients state is changed to
a global variable so that all connections can be accessed within a thread.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/
On Mon, 19 Jun 2023 16:49:05 -0700
"Tristan Partin" wrote:
> On Mon Jun 19, 2023 at 6:39 AM PDT, Yugo NAGATA wrote:
> > On Wed, 24 May 2023 08:58:46 -0500
> > "Tristan Partin" wrote:
> >
> > > On Tue May 23, 2023 at 7:31 PM CDT, Michael Paquier
run" in
pgbench [3]. So, I think it is better to define them separately.
[2] https://www.postgresql.org/docs/current/app-psql.html#id-1.9.4.20.7
[3] https://www.postgresql.org/docs/current/pgbench.html#id=id-1.9.4.11.7
Regards,
Yugo Nagata
> --
> Tristan Partin
> Neon (https://neon.tech)
>
>
--
Yugo NAGATA
On Mon, 5 Jun 2023 11:42:43 -0400
Bruce Momjian wrote:
> On Mon, Jun 5, 2023 at 05:33:51PM +0900, Yugo NAGATA wrote:
> > Hello,
> >
> > On Thu, 18 May 2023 16:49:47 -0400
> > Bruce Momjian wrote:
> >
> > > I have completed the first draft of the P
c5e20298b5fee2849abef86aff
Make materialized views participate in predicate locking
Regards,
Yugo Nagata
> I learned a few things creating it this time:
>
> * I can get confused over C function names and SQL function names in
>commit messages.
>
> * The sections and ord
tion is unnecessary,
as similar to that there are no option to omitting to create tables.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Thu, 1 Jun 2023 23:59:09 +0900
Yugo NAGATA wrote:
> Hello hackers,
>
> Here's a rebased version of the patch-set adding Incremental View
> Maintenance support for PostgreSQL. That was discussed in [1].
> [1]
> https://www.postgre
gregations, and also join it with other tables.
What do you think of using ENR for this way?
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/executor/spi.c b/src/backend/executor/spi.c
index e3a170c38b..27e94ecc87 100644
--- a/src/backend/executor/spi.c
+++ b/src/backend/executor/spi.
useful to identify a problematic row when
an error like
"ERROR: unexpected chunk number ... (expected ...) for toast value"
occurs.
The patch is a just a concept patch and not including documentation
and tests.
What do you think about this feature?
Regards,
Yugo Nagata
--
Yugo
ption before an interval second without
option is prohibited.
postgres=# select 1 \watch interval=3 4
\watch: incorrect interval value '4'
I think it is ok, but this error message seems not user-friendly because,
in the above example, interval values itself is correct, but it seems just
a syntax error. I wonder it is better to use "watch interval must be specified
only once" or such here, as the past patch.
+
+If number of iterations is specified - query will be executed only
+given number of times.
+
Is it common to use "-" here? I think using comma like
"If number of iterations is specified, "
is natural.
Regards,
Yugo Nagata
--
Yugo NAGATA
Number of times the
portal was executed". I'm worried that this makes users confused. For example,
a user may think the average numbers of rows returned by a statement is given by
rows/calls, but it is not always correct because some statements could be
executed
with multiple portal runs.
Al
gt; [27022:walsender] DETAIL: The connection user "r1" requires the REPLICATION
> attribute.
However, if we need this change, how about using
"DETAIL: The connection user "r1" must have the REPLICATION attribute."
This pattern is used in other part like check_objec
;--help" might be intended rather than "--version" to check
supported options? Even so, ctags would have other option whose name contains
"-e" than Emacs support, so this check could end in a wrong result. Therefore,
it seems to me that it is better to check immediately if e
the commit make_etags on Mac failed anyway. Do we want make_etags to
> restore the previous behavior? i.e. 'etags' program not found
>
> >> If so, we should revert the changes of make_etags by the commit and
> >> make make_etags work with that ctags?
>
&
On Wed, 01 Feb 2023 11:47:23 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Antonin Houska wrote:
> >> While working on [1] I noticed that if RLS gets enabled, the COPY TO
> >> command
> >> includes the contents of child table into the result, although t
.
However, I think we would want a comment on the added line. Also, the
attached test should be placed in the regression test.
Regards,
Yugo Nagata
>
> [1] https://commitfest.postgresql.org/41/3641/
>
> --
> Antonin Houska
> Web: https://www.cybertec-postgresql.com
>
--
Yugo NAGATA
ract" both JSON blobs so that the 'newrow' only
> contains the members that differ? I would like to have this:
>
> ─[ RECORD 1
> ]
> op │ U
> datetime │ 2023-02-01 01:16:44.704036+01
> oldrow │ {"year": 2021, "brand": "Sunrise", "winery": "Concha y Toro",
> "bottles": 12, "variety": "Chardonnay"}
> newrow │ {"bottles": 108}
> ─[ RECORD 2
> ]
> op │ U
> datetime │ 2023-02-01 01:16:44.704036+01
> oldrow │ {"year": 2022, "brand": "Sunrise", "winery": "Concha y Toro",
> "bottles": 12, "variety": "Merlot"}
> newrow │ {"bottles": 132}
>
> --
> Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
> "La gente vulgar sólo piensa en pasar el tiempo;
> el que tiene talento, en aprovecharlo"
>
>
--
Yugo NAGATA
On Wed, 1 Feb 2023 16:52:07 +1300
David Rowley wrote:
> On Wed, 1 Feb 2023 at 15:53, Yugo NAGATA wrote:
> > Maybe, you missed to set plan_cache_mode to force_generic_plan.
> > "Subplan Removed" doesn't appear when using a custom plan.
>
> I wouldn't
On Wed, 1 Feb 2023 14:37:27 +0800
Julien Rouhaud wrote:
> Hi,
>
> On Tue, Jan 31, 2023 at 11:17:22AM +0900, Yugo NAGATA wrote:
> >
> > On Mon, 30 Jan 2023 16:05:52 -0500
> > Tom Lane wrote:
> >
> > > If you have no update script, why call it a
$2) AND (b <= $3))
-> Seq Scan on ab_a2_b3 ab_3 (actual rows=0 loops=1)
Filter: ((a >= $1) AND (a <= $2) AND (b <= $3))
(8 rows)
Regards,
Yugo Nagata
--
Yugo NAGATA
Hi,
Thank you for your comment.
On Mon, 30 Jan 2023 16:05:52 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Currently, even when we don't need to execute any command to update an
> > extension from one version to the next, we need to provide an update
> > scrip
te scripts and the list of updates specified in updates_without_script.
Presence of update script has higher priority than the option. Therefore,
if an update script is provided, the script will be executed even if this
update is specified in updates_without_script.
What do you think of this featu
On Thu, 1 Dec 2022 15:48:21 +0900
Michael Paquier wrote:
> On Tue, Oct 18, 2022 at 05:29:58PM +0900, Yugo NAGATA wrote:
> > Thank you for your review. I agree that an isolation test is required.
> > The attached patch contains the test using the scenario as explained in
> &
I was thinking about this point, and it seems to me that we could just
> do s/the given subquery/a subquery/. But perhaps you have a different
> view on the matter?
+1
I also was just about to send a patch updated as so, and this is attached.
Regards,
Yugo Nagata
> --
> Michael
--
Yug
Hello,
I found that qual_is_pushdown_safe() has an argument "subquery"
that is not used in the function. This argument has not been
referred to since the commit 964c0d0f80e485dd3a4073e073ddfd9bfdda90b2.
I think we can remove this if there is no special reason.
Regards,
Yugo Nagata
On Thu, 10 Nov 2022 15:33:37 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Tom Lane wrote:
> >> Hmm. Maybe the right way to think about this is "if we have completed an
> >> EXECUTE, and not yet received a following SYNC, then report that we are in
> &g
solution,
although I have once withdrawn this for not breaking backward compatibility.
Attached is the same patch of [1].
[1]
https://www.postgresql.org/message-id/20220728105134.d5ce51dd756b3149e9b9c52c%40sraoss.co.jp
Regards,
Yugo Nagata
--
Yugo NAGATA
On Wed, 09 Nov 2022 11:17:29 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Tom Lane wrote:
> >> What do you think of the attached wording?
>
> > It looks good to me. That describes the expected behaviour exactly.
>
> Pushed that, then.
Thank you.
> &g
On Sun, 06 Nov 2022 12:54:17 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> >> The attached patch tries to add comments explaining it on the functions.
>
> > I forward it to the hackers list because the patch is to fix comments.
>
> What do you think of the attached
tags -e) and it was
just for testing the patch. Similarly, someone who runs mistakenly this
command might want this option. However, as you say, there've been no
complain about this, so I don't feel it necessary so much. Maybe, users
of this command would be able to remove tags by their selves easily.
Regards,
Yugo Nagata
--
Yugo NAGATA
101 - 200 of 536 matches
Mail list logo
