On Fri, 26 Apr 2024 12:23:45 +0200
Matthias van de Meent wrote:
> On Fri, 26 Apr 2024 at 10:54, Yugo NAGATA wrote:
> >
> > On Wed, 24 Apr 2024 16:08:39 -0500
> > Nathan Bossart wrote:
> >
> > > On Tue, Apr 23, 2024 at 11:47:38PM -0400, Tom Lane wrote:
>
tion or some way
to convert a offset to chunk_seq.
Regards,
Yugo Nagata
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
--
Yugo NAGATA
On Thu, 25 Apr 2024 10:26:41 +0200
Peter Eisentraut wrote:
> On 24.04.24 15:25, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> On 24.04.24 11:59, Yugo NAGATA wrote:
> >>> I noticed that a permission check is performed in be_lo_put()
> >>> just afte
k;
+1
I prefer the new function names since it seems more natural and easier to read.
I noticed pqTraceOutputNR() is left as is, is this intentional? Or, shoud this
be changed to pqTranceOutput_NoticeResponse()?
Regards,
Yugo Nagata
> (This also improves the readability of the file in gene
Hi,
I noticed that a permission check is performed in be_lo_put()
just after returning inv_open(), but teh permission should be
already checked in inv_open(), so I think we can remove this
part of codes. I attached a patch for this fix.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src
"missing {support function | operator} %d(%u,%u) in opfamily %u"
in several places.
Regards,
Yugo Nagata
>
> maybe
> if (!OidIsValid(equality_op)) /* shouldn't happen */
> elog(ERROR, "missing operator =(%u,%u) in opfamily %u",opcintype,
> opcintype, opfam
PRIVILEGES ] }
ON TABLES
TO { [ GROUP ] role_name | PUBLIC } [, ...] [ WITH GRANT OPTION ]
I attached a small patch to fix the description.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/doc/src/sgml/ref/alter_default_privileges.sgml b/doc/src/sgml/ref/alter_default_privileges.
On Tue, 23 Apr 2024 23:47:38 -0400
Tom Lane wrote:
> Yugo NAGATA writes:
> > Currently, ALTER DEFAULT PRIVILEGE doesn't support large objects,
> > so if we want to allow users other than the owner to use the large
> > object, we need to grant a privilege on it ever
to be specified
for large objects since any large objects don't belong to a schema.
The attached patch is originally proposed by Haruka Takatsuka
and some fixes and tests are made by me.
Regards,
Yugo Nagata
--
Yugo NAGATA
>From fe2cb39bd83d09a052d5d63889acd0968c1817b6 Mon Sep 17 00:00:00 2
und in [1].
[1]
https://www.postgresql.org/message-id/20240207101903.b5846c25808f64a91ee2e7a2%40sraoss.co.jp
Regards,
Yugo Nagata
> --
> Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
> "La fuerza no está en los medios físicos
> sino que re
On Thu, 14 Mar 2024 11:10:42 -0500
Nathan Bossart wrote:
> On Wed, Mar 13, 2024 at 01:09:18PM +0700, Yugo NAGATA wrote:
> > On Tue, 12 Mar 2024 22:07:17 -0500
> > Nathan Bossart wrote:
> >> I did some light editing to prepare this for commit.
> >
> >
On Tue, 12 Mar 2024 22:07:17 -0500
Nathan Bossart wrote:
> I did some light editing to prepare this for commit.
Thank you. I confirmed the test you improved and I am fine with that.
Regards,
Yugo Nagata
>
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
--
Yugo NAGATA
On Sat, 9 Mar 2024 08:50:28 -0600
Nathan Bossart wrote:
> On Sat, Mar 09, 2024 at 11:57:18AM +0900, Yugo NAGATA wrote:
> > On Fri, 8 Mar 2024 16:17:58 -0600
> > Nathan Bossart wrote:
> >> Is this guaranteed to be TOASTed for all possible page sizes?
> >
On Fri, 08 Mar 2024 12:09:12 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > On Wed, 06 Mar 2024 13:03:39 -0500
> > Tom Lane wrote:
> >> I don't have Windows here to test on, but does the WIN32 code
> >> path work at all?
>
> > The outer loop is ev
On Fri, 8 Mar 2024 16:17:58 -0600
Nathan Bossart wrote:
> On Fri, Mar 08, 2024 at 03:31:55PM +0900, Yugo NAGATA wrote:
> > On Thu, 7 Mar 2024 16:56:17 -0600
> > Nathan Bossart wrote:
> >> to me. Do you think it's worth adding something like a
> >> pg_c
On Thu, 7 Mar 2024 16:56:17 -0600
Nathan Bossart wrote:
> On Mon, Feb 05, 2024 at 04:28:23PM +0900, Yugo NAGATA wrote:
> > On Thu, 1 Feb 2024 17:59:56 +0800
> > jian he wrote:
> >> v6 patch looks good.
> >
> > Thank you for your review and updating the
e
cancel at this timing because currently we use PQsendQuery which is asynchronous
and does not wait the result. We have to check cancel_pressed after PQgetResult
call. I'm also attached a patch for this, with some comments fix.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/bin/psql/co
On Wed, 06 Mar 2024 13:03:39 -0500
Tom Lane wrote:
> Michael Paquier writes:
> > On Tue, Mar 05, 2024 at 10:05:52PM +0900, Yugo NAGATA wrote:
> >> In the current code of do_watch(), sigsetjmp is called if WIN32
> >> is defined, but siglongjmp is not c
remove code around sigsetjmp in
do_watch(). I've attached the patch for this fix.
Regards,
Yugo Ngata
--
Yugo NAGATA
diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c
index 5c906e4806..c03e47744e 100644
--- a/src/bin/psql/command.c
+++ b/src/bin/psql/command.c
@@ -5312,20 +5312,10
sult rows to
"dest_new". And, replace_rte_with_delta updates the input argument "rte"
and returns the result to it, so it may be better that this returns void,
as you suggested.
Regards,
Yugo Nagata
--
Yugo NAGATA
, so I wonder the Assert condition would be a bit complex. Could
you explain what are you assume about like for example?
Regards,
Yugo Nagata
--
Yugo NAGATA
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,
> &g
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
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.
> > > > b
ike "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
ee 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 here?
Regards,
Yugo Na
;
> 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
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 in
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.
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:
> > > &g
, 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
leted 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
was 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
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 97af1b2300ecf07a34923da87a9d84e6a
equired 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.sr
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;
> >>
>
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 rewri
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
.
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
> >>> 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
"
>
> 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
t; command for an
incrementally maintained materialized view.
Regards,
Yugo Nagata
--
Yugo NAGATA
ml/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
> >> worst
&g
hose "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
> worst
>
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
ings...
>
> 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 attached the upd
-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 ($std
lified 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 investigate whether
this can be used in
g 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, thread #0 will be
interrupt
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
> > > "inv
e 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
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 immediatel
top 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 and Windows versions would
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,
> >
&
h, 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 used my
s/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
>
> --
> Regards,
&g
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 of t
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
at 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/src/b
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
uot; 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 t
298b5fee2849abef86aff
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 orde
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.postgresql.o
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.
lso 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
--
Yug
1 - 100 of 454 matches
Mail list logo