te line.
>
> Okay for me as long as the patch is pushed to master branch.
>
> A small comment on the comments in the patch: pgindent dislikes some
> of the comment indentation styles. See attached pgindent.txt. Although
> such a small defect would be fixed by committers when
tency stddev = 466.328 ms
- statement latencies in milliseconds and failures:
0.426 0 begin;
5352.229 0 lock b;
2003.416 0 select pg_sleep(2);
0.829 3 lock a;
8.774 0 end;
I've attached the update
of faild transactions. Also, I added a check of script_total_cnt before
reporting per-script number of failed transactions.
Regards,
Yugo Nagata
--
Yugo Nagata
>From 000340660f2c567164d7f33cf622f8225a046262 Mon Sep 17 00:00:00 2001
From: Yugo Nagata
Date: Thu, 19 Sep 2024 01:37:54 +0900
On Fri, 26 Apr 2024 17:54:06 +0900
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:
> > > On the whole I find this proposed feature pretty unexciting
> > > and dubio
On Thu, 12 Sep 2024 19:51:33 +0900
Yugo NAGATA wrote:
> On Thu, 12 Sep 2024 19:07:22 +0900
> Fujii Masao wrote:
>
> >
> >
> > On 2024/09/10 17:45, Yugo NAGATA wrote:
> > > On Mon, 9 Sep 2024 22:59:34 +0900
> > > Fujii Masao wrote:
> > >
On Thu, 12 Sep 2024 19:07:22 +0900
Fujii Masao wrote:
>
>
> On 2024/09/10 17:45, Yugo NAGATA wrote:
> > On Mon, 9 Sep 2024 22:59:34 +0900
> > Fujii Masao wrote:
> >
> >>
> >>
> >> On 2024/07/02 16:34, Yugo NAGATA wrote:
> >>>
On Mon, 9 Sep 2024 22:59:34 +0900
Fujii Masao wrote:
>
>
> On 2024/07/02 16:34, Yugo NAGATA wrote:
> > So, I would like to propose to add
> > has_large_object_function for checking if a user has the privilege on a
> > large
> > object.
>
> +1
Tha
On Mon, 9 Sep 2024 12:16:01 +0900
Michael Paquier wrote:
> On Fri, Sep 06, 2024 at 08:10:43PM +0900, Yugo Nagata wrote:
> > Since 1bb2558046c, XLogFileRead() doesn't use the emode argument.
> > Also, since abf5c5c9a4f, XLogFileReadAnyTLI() is called just once
> > and
,
the function returns without using newExpectedTLEs, nor releasing it. I wonder
this is a memory leak and it is better to release it, although the affect may
be not so much.
I've attached the patch.
Regards,
Yugo Nagata
--
Yugo Nagata
diff --git a/src/backend/access/transam/xlogrecover
Hi,
Since 1bb2558046c, XLogFileRead() doesn't use the emode argument.
Also, since abf5c5c9a4f, XLogFileReadAnyTLI() is called just once
and emode is always DEBUG2. So, I think we can remove the emode
argument from these functions. I've atached the patch.
Regards,
Yugo Nagata
--
Y
On Thu, 22 Aug 2024 09:10:52 +0200
Peter Eisentraut wrote:
> On 22.08.24 08:15, Yugo Nagata wrote:
> > On Thu, 22 Aug 2024 11:38:49 +0800
> > jian he wrote:
> >
> >> On Wed, Aug 21, 2024 at 4:57 PM Peter Eisentraut
> >> wrote:
> >>>
> &g
rrhint is wrong?
Yes. I think we don't have to output the hint message if we disallow USING
for generated columns. Or, it may be useful to allow only a simple cast
for the generated column instead of completely prohibiting USING.
Regards,
Yugo Nagata
--
Yugo Nagata
is patch adds a check to error out if this is specified.
I’m afraid you forgot to attach the patch.
It seems for me that this fix is reasonable though.
Regards,
Yugo Nagata
>
> There was a test for this, but that test errored out for a different
> reason, so it was not effective.
>
&g
ry server respectively, it is not surprising that s2 has progressed
far than s1 when the primary fails. I believe that this is the case you should
use pg_rewind. Even if flushedUpto is reset as proposed in your patch, s2 might
already have applied a WAL record that s1 has not processed yet, and there
would be no gurantee that subsecuent applys suceed.
Regards,
Yugo Nagata
--
Yugo Nagata
xist, error out */
> if (stat(XLOGDIR, &stat_buf) != 0 ||
> !S_ISDIR(stat_buf.st_mode))
Should be the follwing also rewritten using sizeof(PG_REPLSLOT_DIR)?
struct stat statbuf;
charpath[MAXPGPATH * 2 + 12];
Regards,
Yugo Nagata
--
Yugo Nagata
er ad d the same comment in dropdb(). I attached a trivial
patch for it.
Regards,
Yugo Nagata
--
Yugo Nagata
diff --git a/src/backend/commands/dbcommands.c b/src/backend/commands/dbcommands.c
index 7a7e2c6e3e..d00ae40e19 100644
--- a/src/backend/commands/dbcommands.c
+++ b/src/backend/com
ce should start with "This ... ".
> >
> > + while(size)
> > + {
> >
> > I wonder inserting a space after "while" is the standard style.
>
> Thanks, fixed.
Should we fix the comment on byteaGetByte in passing, too?
Regards,
Yugo Nagata
--
Yugo Nagata
as the newvalue argument
useful? I wonder it would eliminate the restrict that size cannot be larger
than 8.
Here are my very trivial comments on the patch.
+ * this routine treats "bytea" as an array of bytes.
Maybe, the sentence should start with "This ... ".
+ while
!= NULL)
{
charpath[MAXPGPATH + 12];
PGFileType de_type;
I think the size of path can be rewritten to "MAXPGPATH +
sizeof(PG_REPLSLOT_DIR)"
and it seems easier to understand the reason why this size is used.
(That said, I wonder the path would never longer than MAXPGPATH...)
Regards,
Yugo Nagata
>
> Regards,
>
> --
> Bertrand Drouvot
> PostgreSQL Contributors Team
> RDS Open Source Databases
> Amazon Web Services: https://aws.amazon.com
--
Yugo Nagata
On Tue, 06 Aug 2024 11:24:03 -0700
Jeff Davis wrote:
> On Wed, 2024-08-07 at 03:06 +0900, Yugo Nagata wrote:
> > I'm sorry. After sending the mail, I found the patch didn't work.
> > If we call RestrictSearchPath() before creating a relation, it tries
> > to create
On Wed, 7 Aug 2024 02:13:04 +0900
Yugo Nagata wrote:
> On Thu, 01 Aug 2024 13:34:51 -0700
> Jeff Davis wrote:
>
> > On Fri, 2024-08-02 at 00:13 +0500, Kirill Reshke wrote:
> > > On Thu, 1 Aug 2024 at 23:27, Jeff Davis wrote:
> > > >
> > > > EXP
ersions, so we've lived with it for a while, and
> I don't see a security problem here. I wouldn't expect it to be a
> common use case, either.
I agree that we don't have to rush it since it is not a security bug
but just it could make a materialized view that cannot be ref
ld make EXPLAIN support REFRESH MATERIALIZED VIEW CONCURRENTLY
command, how should we handle these additional queries?
Regards,
Yugo Nagata
--
Yugo Nagata
On Fri, 2 Aug 2024 16:13:01 +0900
Yugo NAGATA wrote:
> On Thu, 01 Aug 2024 11:31:53 -0700
> Jeff Davis wrote:
>
> > On Wed, 2024-07-31 at 18:20 +0900, Yugo NAGATA wrote:
> > > I agree that it might not be important, but I think adding the flag
> > > would be
On Thu, 01 Aug 2024 11:31:53 -0700
Jeff Davis wrote:
> On Wed, 2024-07-31 at 18:20 +0900, Yugo NAGATA wrote:
> > I agree that it might not be important, but I think adding the flag
> > would be
> > also helpful for improving code-readability because it clarify the
> >
Hi,
On Fri, 26 Jul 2024 16:47:23 -0700
Jeff Davis wrote:
> Hello,
>
> Thank you for looking.
>
> On Fri, 2024-07-26 at 12:26 +0900, Yugo Nagata wrote:
> > Since this commit, matviews are no longer handled in
> > ExecCreateTableAs, so the
> > following
Hi,
On Tue, 30 Jul 2024 01:36:55 +0200
Erik Wienhold wrote:
> On 2024-07-01 15:08 +0200, Yugo NAGATA wrote:
> > I would like to propose to add a new field to psql's \dAo+ meta-command
> > to show whether the underlying function of an operator is leak-proof.
>
> +1 f
ted.
Thank you so much for a lot of comments!
I will respond to the comments soon.
> >
> > On Thu, 11 Jul 2024 at 09:24, Yugo NAGATA wrote:
> > >
> > > I updated the patch to bump up the version numbers in psql and pg_dump
> > > codes
> > >
L
as queryEnv arg in CreateQueryDesc to avoid to create useless matviews
accidentally,
as the attached patch?
Regards,
Yugo Nagata
--
Yugo Nagata
diff --git a/src/backend/commands/createas.c b/src/backend/commands/createas.c
index e91920ca14..fda1e4d92b 100644
--- a/src/backend/commands/createas
t
the previous
LSN segment number when the LSN was on a file segment boundary; it now
returns the LSN segment.
It might be trivial, but, reading the associated commit message , I think it
would be more explicit
for users to rewrite the last statement to
"it now returns the current LSN se
freshMatView since this is public
for a
long time, but I don't think the new interface RefreshMatViewByOid has to have
this
unused argument.
I attaehd patches for fixing them respectedly.
What do you think about it?
Regards,
Yugo Nagata
--
Yugo Nagata
>From 854d01bfbdece781bad46ab68
On Thu, 4 Jul 2024 11:06:03 +0200
Jelte Fennema-Nio wrote:
> On Thu, 4 Jul 2024 at 06:46, Yugo NAGATA wrote:
> > Attached is a small patch to fix a comment on PQcancelErrorMessage.
>
> Oops, copy paste mistake on my part I guess. New comment LGTM
Thank you for your comments.
I
Hi,
Attached is a small patch to fix a comment on PQcancelErrorMessage.
It was accidentally "Get the socket of the cancel connection."
I rewrote it to "Returns the error message most recently generated
by an operation on the cancel connection."
Regards,
Yugo Nagata
--
Yug
ct id is
specified, and false if non-existing user id is specified, and raises an error
if
non-existing user name is specified. These behavior is similar with
has_table_privilege.
The regression test is also included.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Sun, 23 Jun 2024 19:14:09 +0900
Yugo NAGATA wrote:
> and Operator Families"? Additionally, is it useful to add LEAKPROOF
> information
> to the result of psql \dAo(+) meta-comand, or a function that can check given
> index
> or operator is leakproof or not?
I worte a p
The attached patch adds the field to \dAo+ and also a description that
explains the relation between indexes and security quals with referencing
\dAo+ meta-command.
[1]
https://www.postgresql.org/message-id/raw/5af3bf0c-5e0c-4128-81dc-084c5258b1af%40code406.com
Regards,
Yugo Nagata
--
Yugo N
ongpathexample2ple1
In the current uses, BackupState is freed (by pfree or MemoryContextDelete)
after each use of BackupState, so the memory space is not reused as your
scenario above, and there would not harms even if the null-termination is
omitted.
However, I wonder it is better to use strlcpy without assuming such the good
manner of callers.
Regards,
Yugo Nagata
>
> It's not a good idea to use memcpy with strlen.
>
> best regards,
> Ranier Vilela
--
Yugo NAGATA
On Mon, 24 Jun 2024 08:37:26 -0300
Ranier Vilela wrote:
> Em seg., 24 de jun. de 2024 às 00:27, Yugo NAGATA
> escreveu:
>
> > On Sun, 23 Jun 2024 22:34:03 -0300
> > Ranier Vilela wrote:
> >
> > > Em dom., 23 de jun. de 2024 às 22:14, Ranier Vilela >
On Tue, 18 Jun 2024 23:02:14 -0700
"David G. Johnston" wrote:
> On Tuesday, June 18, 2024, Tom Lane wrote:
>
> > Yugo NAGATA writes:
> > > On Tue, 18 Jun 2024 20:56:58 -0700
> > > "David G. Johnston" wrote:
> > >> But it is n
change the size of the field,
but if change it, I wonder it is better to modify the following
message from MAXPGPATH to MAXPGPATH -1.
errmsg("backup label too long (max %d bytes)",
MAXPGPATH)));
Regards,
Yugo Nagata
>
> So, I think that v3 is ok to fix.
>
> best regards,
> Ranier Vilela
>
> >
> > best regards,
> > Ranier Vilela
> >
> >>
--
Yugo NAGATA
ation familiar, for example, "11.10. Operator
Classes
and Operator Families"? Additionally, is it useful to add LEAKPROOF information
to the result of psql \dAo(+) meta-comand, or a function that can check given
index
or operator is leakproof or not?
Regards,
Yugo Nagata
> Thanks
#x27;s good for amcostestimate() to modify the
>
> IndexPath directly as the PoC patch does.
I am not sure it is the best way to modify IndexPath in amcostestimate(), but
I don't have better ideas for now.
Regards,
Yugo Nagata
>
>
>
>
> Regards,
>
> --
>
> Masahiro Ikeda
>
> NTT DATA CORPORATION
>
>
--
Yugo NAGATA
On Tue, 18 Jun 2024 20:56:58 -0700
"David G. Johnston" wrote:
> On Tue, Jun 18, 2024 at 8:34 PM Yugo NAGATA wrote:
>
> >
> > It may be a trivial thing but I am not sure we need to mention case
> > insensitivity
> > here, because all keywords and unqu
vial thing but I am not sure we need to mention case
insensitivity
here, because all keywords and unquoted identifiers are case-insensitive in
PostgreSQL and it is not specific to NULL.
Also, I found the other parts of the documentation use "case-insensitive" in
which
words are joined with hyphen, so I wonder it is better to use the same form if
we
leave the description.
Regards,
Yugo Nagata
--
Yugo NAGATA
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:
>
re offset information 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
>Pfdebug, message, &logCursor);
> break;
+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
>
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,
> opcint
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 every
ed 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
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 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
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
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 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
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
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
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
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
1 - 100 of 501 matches
Mail list logo
