On Mon, 19 Jul 2021 17:47:07 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Mon, 19 Jul 2021 16:00:39 +0900, Yugo NAGATA wrote
> in
> > Your patch doesn't fix the issue that the error message is never reported in
> > standby mode. When a WAL page header is broken, the
On Mon, 19 Jul 2021 06:32:28 -0300
Ranier Vilela wrote:
> Em seg., 19 de jul. de 2021 às 06:15, Yugo NAGATA
> escreveu:
>
> > On Mon, 19 Jul 2021 17:47:07 +0900 (JST)
> > Kyotaro Horiguchi wrote:
> >
> > > At Mon, 19 Jul 2021 16:00:39 +0900, Yugo NAG
On Tue, 13 Jul 2021 11:59:49 +0900
Yugo NAGATA wrote:
> Hello,
>
> During reading the documentation of libpq [1] , I found the following
> description:
>
> In the nonblocking state, calls to PQsendQuery, PQputline, PQputnbytes,
> PQputCopyData, and PQendcopy will not blo
ns. Specifically, we don't return a
* divide-by-zero error code for 0 ^ -1.
*/
In the original code, two checks that could raise an error of
ERRCODE_INVALID_ARGUMENT_FOR_POWER_FUNCTION are following the comment.
I think these check codes are placed together under this comment intentionally,
so I suggest not to move one of them.
Regards,
Yugo Nagata
--
Yugo NAGATA
Hello Alvaro,
On Tue, 20 Jul 2021 12:05:11 -0400
Alvaro Herrera wrote:
> On 2021-Jul-19, Yugo NAGATA wrote:
>
> > On Tue, 13 Jul 2021 11:59:49 +0900
> > Yugo NAGATA wrote:
>
> > > However, looking into the code, PQsendQuery seems not to return an error
>
On Mon, 19 Jul 2021 10:51:36 +0900
Yugo NAGATA wrote:
> Hello Fabien,
>
> On Sat, 17 Jul 2021 07:03:01 +0200 (CEST)
> Fabien COELHO wrote:
>
> >
> > Hello Yugo-san,
> >
> > > [...] One way to avoid these errors is to send Parse messages before
>
On Wed, 21 Jul 2021 11:10:16 +0100
Dean Rasheed wrote:
> On Tue, 20 Jul 2021 at 10:17, Yugo NAGATA wrote:
> >
> > This patch fixes numeric_power() to handle negative bases correctly and not
> > to raise an error "cannot take logarithm of a negative number", as
it is already done at the end of transaction (i.e.,
CSTATE_END_TX).
We need disconnection here only when we get an error.
Therefore, we don't need the measurement here.
I attached the updated patch.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbenc
Hello Fujii-san,
On Wed, 28 Jul 2021 00:20:21 +0900
Fujii Masao wrote:
>
>
> On 2021/07/27 11:02, Yugo NAGATA wrote:
> > Hello Fujii-san,
> >
> > Thank you for looking at it.
> >
> > On Tue, 27 Jul 2021 03:04:35 +0900
> > Fujii Masao wrote:
Hello,
On Fri, 18 Jun 2021 15:58:48 +0200 (CEST)
Fabien COELHO wrote:
> Attached Yugo-san patch with some updates discussed in the previous mails,
> so as to move things along.
I attached the patch rebased to a change due to 856de3b39cf.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff -
Hello Fujii-san,
On Fri, 30 Jul 2021 02:01:08 +0900
Fujii Masao wrote:
>
>
> On 2021/07/29 2:23, Fujii Masao wrote:
> >
> >
> > On 2021/07/28 16:15, Yugo NAGATA wrote:
> >>> I found another disconnect_all().
> >>>
> >>> /*
On Fri, 30 Jul 2021 15:26:51 +0900
Fujii Masao wrote:
>
>
> On 2021/07/30 14:43, Yugo NAGATA wrote:
> > This patch fixes three issues of connection time measurement:
> >
> > 1. The initial connection time is measured and stored into conn_duration
> > bu
Hello Zhihong Yu,
On Mon, 2 Aug 2021 14:33:46 -0700
Zhihong Yu wrote:
> On Sun, Aug 1, 2021 at 11:30 PM Yugo NAGATA wrote:
>
> > Hi hackers,
> >
> > On Mon, 19 Jul 2021 09:24:30 +0900
> > Yugo NAGATA wrote:
> >
> > > On Wed, 14 Jul 2021 21:22:37
: Create an index on the materialized view for efficient incremental
> maintenance.
> ERROR: "foreign_table" is a foreign table
> DETAIL: Triggers on foreign tables cannot have transition tables.
>
> It finally failed to make IVM, but I think it should be checked more early.
You are right. We don't support foreign tables as long as we use triggers.
I'll fix.
Regards,
Yugo Nagata
--
Yugo NAGATA
Hello Fujii-san,
On Thu, 5 Aug 2021 16:16:48 +0900
Fujii Masao wrote:
>
>
> On 2021/08/01 14:50, Yugo NAGATA wrote:
> > When -C is not specified, the disconnection time is not measured even in
> > the patch for v14+. I don't think it is a problem because the
> >
On Tue, 10 Aug 2021 10:50:20 -0400
Greg Sabino Mullane wrote:
> Apologies, just saw this. I found no problems, those "failures" were just
> me missing checkboxes on the commitfest interface. +1 on the patch.
Thank you!
--
Yugo NAGATA
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 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
#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
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
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
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
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 >
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
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
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
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
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
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
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
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,
> >
&
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
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
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
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
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
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
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
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
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
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
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
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
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
, 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
>
; > 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
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:
> > > >
> &
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:
> > >
> &
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
+" command for an
incrementally maintained materialized view.
Regards,
Yugo Nagata
--
Yugo NAGATA
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
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
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
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
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.
"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
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
>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
>
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
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 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:
>
ed, but the DML of
> the base table
> can not be blocked, that is to say, the base table can still record logs
> during incremental refresh,
> as long as we use same snapshot when incrementally updating.
>
> do you think there will be any problems with this solution?
I guess the deferred maintenance process would be basically what similar
to above. Especially, as you say, we need to merge incremental information
in some way before calculating deltas on the view. I investigated some
research papers, but I'll review again before working on deferred approach
design.
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
tion is unnecessary,
as similar to that there are no option to omitting to create tables.
Regards,
Yugo Nagata
--
Yugo NAGATA
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
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
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, 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
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, 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
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 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
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 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
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
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
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
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
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
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
,
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
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
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 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 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 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
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
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
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
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
> > >
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
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
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
> >
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
ld make EXPLAIN support REFRESH MATERIALIZED VIEW CONCURRENTLY
command, how should we handle these additional queries?
Regards,
Yugo Nagata
--
Yugo Nagata
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
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
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
!= 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
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
301 - 400 of 588 matches
Mail list logo
