" (IMMs) would be good. So, how about using this for now?
When other better opinions are raised, let's discuss again
Regards,
Yugo Nagata
>
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo Nagata
The following review on our patch was posted on another thread,
so I quote here. The tab completion is Hoshiai-san's work, so
he will handle this issue.
Regards,
Yugo Nagata.
On Thu, 28 Nov 2019 13:00:05 +0900
nuko yokohama wrote:
> Hi.
>
> I'm using the "Incre
Hello nuko-san,
Thank you for your review!
As Michael commentted, we would like to discuss this on the thread
of the patch, so I quote your review in the following post.
https://www.postgresql.org/message-id/20191129154513.943f4ef05896d7b9d3fed69f%40sraoss.co.jp
Regards,
Yugo Nagata
On Thu
e could use combine functions to calculate new
aggregate values in IVM when tuples are inserted into a table. However, in
the context of IVM, we also need other function used when tuples are deleted
from a table, so we can not use partial aggregation for IVM in the current
implementation. This might be
ng it isolated seems
> like a good way to attract more eyeballs.
>
> * Someone well versed in trigger infrastructure can help fine tune the
> patch for (2)
>
> and so on.
>
> So, please consider giving some thought to this.
Agreed. Although I am not sure we will do it as above way, we will
consider to split the patch, anyway. Thanks.
Regards,
Yugo Nagata
--
Yugo Nagata
On Fri, 29 Nov 2019 18:16:00 +0900
Yugo Nagata wrote:
> On Fri, 29 Nov 2019 15:34:52 +0900
> Amit Langote wrote:
>
> > Thanks a lot for working on this. It's a great (and big!) feature and
> > I can see that a lot of work has been put into writing this patch. I
able
> > to handle correctly. Supported aggregates can be identified using their
> > OIDs.
> > User-defined aggregates are not supported. I think this is the simplest and
> > easiest way.
>
> I think this is enough for the first cut of IVM. So +1.
If there is no objection, I will add the check of aggregate functions
by this way. Thanks.
Regards,
Yugo Nagata
--
Yugo Nagata
On Mon, 2 Dec 2019 13:48:40 -0300
Alvaro Herrera wrote:
> On 2019-Dec-02, Yugo Nagata wrote:
>
> > On Mon, 02 Dec 2019 10:36:36 +0900 (JST)
> > Tatsuo Ishii wrote:
> >
> > > >> One thing pending in this development line is how to catalogue
> >
table will fail.
>
> Error message.
> ```
> ERROR: could not open relation with OID 0
Thank you for your pointing out this issue! This error occurs
because the view's OID is retrieved using the view name.
Considering that the name can be changed, this is obviously
wrong. We'l
would be easy for inner joins
or aggregate views, but there is some difficult with outer joins.
Regards,
Yugo Nagata
--
Yugo Nagata
IVM_patches_v10.tar.gz
Description: application/gzip
w returns incorrect results.
> To prevent this, we propose that the same error occur when a non-IMMUTABLE
> expression is specified in the "CREATE INDEX" statement.
Thank you for pointing out this. That makes sense. The check of not-IMMUTABLE
epressions is missing at creating IMMV
ou concern occurs. So, it seems worth to consider the way to
reduce use of temptable.
Regards,
Yugo Nagata
--
Yugo Nagata
On Mon, 23 Dec 2019 08:08:53 +
"tsunakawa.ta...@fujitsu.com" wrote:
> From: Yugo Nagata
> > 1. Create a temporary table only once at the first view maintenance in
> > this session. This is possible if we store names or oid of temporary
> > tables used for e
rg/message-id/flat/157703426606.1198.2452090605041230054.pgcf%40coridan.postgresql.org#331e8344bbae904350af161fb43a0aa6
Although I have not looked into this thread, this may be help if this is
implemented. However, it would be still necessary to truncate the table
before the view maintenance because such tables always exist and can be
accessed and modified by any users.
--
Yugo Nagata
On Tue, 24 Dec 2019 07:07:35 +
"tsunakawa.ta...@fujitsu.com" wrote:
> From: Yugo Nagata
> > On Mon, 23 Dec 2019 08:08:53 +
> > "tsunakawa.ta...@fujitsu.com" wrote:
> > > How about unlogged tables ? I thought the point of using a te
ollowing error message doesn't look good because built-in min is
supported, so I will improve it.
ERROR: aggregate function min is not supported
Regards,
Yugo Nagata
>
> An execution example is shown below.
>
> ```
> [ec2-user@ip-10-0-1-10 ivm]$ cat extension-agg.sql
&
g into the view
> source table (including the user-defined type column).
> ```
> ERROR: operator does not exist
Thank you for your reporting. I think this error occurs because
pg_catalog.= is used also for user-defined types. I will fix this.
Regards,
Yugo Nagata
> ```
>
> An
y problems, as well as performance problems above
> and beyond the one described here.
We realized that there is also other problems in using temp tables
as pointed out in another thread. So, we are now working on rewrite
our patch not to use temp tables.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Fri, 17 Jan 2020 14:10:32 -0700 (MST)
legrand legrand wrote:
> Hello,
>
> It seems that patch v11 doesn't apply any more.
> Problem with "scanRTEForColumn" maybe because of change:
Thank you for your reporting! We will fix this in the next update.
Regar
On Mon, 1 Apr 2019 12:11:22 +0900
Yugo Nagata wrote:
> On Thu, 27 Dec 2018 21:57:26 +0900
> Yugo Nagata wrote:
>
> > Hi,
> >
> > I would like to implement Incremental View Maintenance (IVM) on PostgreSQL.
> >
>
> I am now working on an initial p
On Thu, 1 Mar 2018 14:29:58 -0800
Andres Freund wrote:
> Hi,
>
> On 2018-01-11 11:03:26 +0900, Yugo Nagata wrote:
> > However, I don't inisist on this patch, so If anyone other don't need this
> > feature, I'll withdraw this.
>
> Given this is where
osing a performance
> cost on unrelated queries.
I would like to elaborate my patch if needed and possible. Any suggestion
would be appriciated.
Thanks,
>
> regards, tom lane
--
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
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
* 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.
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
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
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
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
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 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 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 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
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
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
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:
> > > >
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 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 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 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 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
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
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
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
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
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 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.
> > > &
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 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
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
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
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
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
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
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.
> >
> >
oblem I found 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
> s
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,
> >&
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
tion
query, 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
utes the query and the result 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
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 +53
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 called in the
ct the
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/b
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
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 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
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 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
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
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.
On Fri, 25 Mar 2022 09:14:00 +0900 (JST)
Tatsuo Ishii wrote:
> > Note that the \\g2 just above also needs to be changed.
>
> Oops. Thanks. New patch attached. Test has passed on my machine.
This patch works for me. I think it is ok to use \N instead of \gN.
Regards,
Yugo Naga
ded items will be
> precisou information. I would suggest leave the log items as it is.
>
> Patch attached.
Even applying this patch, "make postgres-A4.pdf" arises the warning on my
machine. After some investigations, I found that previous document had a break
after 'num_tr
behavior.
Currently, pgbench fails to execute the above script in prepared mode
because it prepares the entire script in advance just before the first
command execution. This patch does not change the semantic.
> BTW, the cfbot says the patch is failing to apply anyway ...
> I think it was sideswi
s', but it has been removed due to this commit.
>
> Yes, your patch removed "&zwsp;".
>
> > So,
> > I would like to get back this as it was. I attached the patch.
>
> This produces errors. Needs ";" postfix?
Oops. Yes, it needs ';'. A
stion!
Following your advice, I am going to write a readers guide referring to the past
posts of Andres and Rebert.
Regards,
Yugo Nagata
--
Yugo NAGATA
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
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
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
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_
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
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
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 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 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
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 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
.
Regards,
Yugo Nagata
--
Yugo NAGATA
Hi,
On Thu, 13 Jan 2022 18:23:42 +0800
Julien Rouhaud wrote:
> Hi,
>
> On Thu, Nov 25, 2021 at 04:37:10PM +0900, Yugo NAGATA wrote:
> > On Wed, 24 Nov 2021 04:31:25 +
> > "r.takahash...@fujitsu.com" wrote:
> >
> > >
> > > I check
Hello,
I found a old parameter name 'heapRelation' in the comment
of CheckIndexCompatible. This parameter was removed by 5f173040.
Attached is a patch to remove it from the comment.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/commands/indexcmds.c b/src/backen
Hello, Fujii-san,
On Fri, 4 Feb 2022 09:08:22 +0900
Fujii Masao wrote:
>
>
> On 2022/02/04 1:46, Yugo NAGATA wrote:
> > Hello,
> >
> > I found a old parameter name 'heapRelation' in the comment
> > of CheckIndexCompatible. This parameter was remove
On Fri, 18 Feb 2022 12:22:32 +0900
Fujii Masao wrote:
>
>
> On 2022/02/07 19:14, Yugo NAGATA wrote:
> > Agreed. I updated the patch to add a comment about 'oldId'.
>
> Thanks for updating the patch! I slightly modified the patch and pushed it.
Thanks!
>
uences. You
> reported that you got stuck. Hmmm.
>
> I tried again my tests which worked fine when started with 2 clients,
> otherwise they get stuck because the first client waits for the other one
> which does not exists (the point is to generate deadlocks and other
> errors)
eSQL code.
static inline __u32 rol32(__u32 word, unsigned int shift)
{
return (word << (shift & 31)) | (word >> ((-shift) & 31));
}
[1] https://github.com/torvalds/linux/blob/master/include/linux/bitops.h
[2] https://lore.kernel.org/lkml/20190609164129.126354...@linuxfou
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
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
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 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
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
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
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
> &
101 - 200 of 590 matches
Mail list logo
