ber@entry=199) at
> > /home/andrew/pgl/pg_head/src/backend/utils/error/assert.c:69
>
> That assert just got added a few days ago, so that's why the patch
> seemed OK before.
Thank you for letting me know. I'll fix it.
--
Yugo NAGATA
On Tue, 20 Apr 2021 09:51:34 +0900
Yugo NAGATA wrote:
> On Mon, 19 Apr 2021 17:40:31 -0400
> Tom Lane wrote:
>
> > Andrew Dunstan writes:
> > > This patch (v22c) just crashed for me with an assertion failure on
> > > Fedora 31. Here's the stack trace
On Mon, 26 Apr 2021 15:46:21 +0900
Yugo NAGATA wrote:
> On Tue, 20 Apr 2021 09:51:34 +0900
> Yugo NAGATA wrote:
>
> > On Mon, 19 Apr 2021 17:40:31 -0400
> > Tom Lane wrote:
> >
> > > Andrew Dunstan writes:
> > > > This patch (v22c)
On Mon, 26 Apr 2021 16:03:48 +0900
Yugo NAGATA wrote:
> On Mon, 26 Apr 2021 15:46:21 +0900
> Yugo NAGATA wrote:
>
> > On Tue, 20 Apr 2021 09:51:34 +0900
> > Yugo NAGATA wrote:
> >
> > > On Mon, 19 Apr 2021 17:40:31 -0400
> > > Tom Lane
On Fri, 7 May 2021 14:14:16 +0900
Yugo NAGATA wrote:
> On Mon, 26 Apr 2021 16:03:48 +0900
> Yugo NAGATA wrote:
>
> > On Mon, 26 Apr 2021 15:46:21 +0900
> > Yugo NAGATA wrote:
> >
> > > On Tue, 20 Apr 2021 09:51:34 +0900
> > > Yugo NAGATA wrote
LE, and I heard
> > > that a couple of forks already ship Marina's patch set.
I got interested in this and now looking into the patch and the past
discussion.
If anyone other won't do it and there are no objection, I would like to rebase
this. Is that okay?
Regards,
Y
te scripts and the list of updates specified in updates_without_script.
Presence of update script has higher priority than the option. Therefore,
if an update script is provided, the script will be executed even if this
update is specified in updates_without_script.
What do you think of this featu
Hi,
Thank you for your comment.
On Mon, 30 Jan 2023 16:05:52 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Currently, even when we don't need to execute any command to update an
> > extension from one version to the next, we need to provide an update
> > scrip
$2) AND (b <= $3))
-> Seq Scan on ab_a2_b3 ab_3 (actual rows=0 loops=1)
Filter: ((a >= $1) AND (a <= $2) AND (b <= $3))
(8 rows)
Regards,
Yugo Nagata
--
Yugo NAGATA
On Wed, 1 Feb 2023 14:37:27 +0800
Julien Rouhaud wrote:
> Hi,
>
> On Tue, Jan 31, 2023 at 11:17:22AM +0900, Yugo NAGATA wrote:
> >
> > On Mon, 30 Jan 2023 16:05:52 -0500
> > Tom Lane wrote:
> >
> > > If you have no update script, why call it a
On Wed, 1 Feb 2023 16:52:07 +1300
David Rowley wrote:
> On Wed, 1 Feb 2023 at 15:53, Yugo NAGATA wrote:
> > Maybe, you missed to set plan_cache_mode to force_generic_plan.
> > "Subplan Removed" doesn't appear when using a custom plan.
>
> I wouldn't
ract" both JSON blobs so that the 'newrow' only
> contains the members that differ? I would like to have this:
>
> ─[ RECORD 1
> ]
> op │ U
> datetime │ 2023-02-01 01:16:44.704036+01
> oldrow │ {"year": 2021, "brand": "Sunrise", "winery": "Concha y Toro",
> "bottles": 12, "variety": "Chardonnay"}
> newrow │ {"bottles": 108}
> ─[ RECORD 2
> ]
> op │ U
> datetime │ 2023-02-01 01:16:44.704036+01
> oldrow │ {"year": 2022, "brand": "Sunrise", "winery": "Concha y Toro",
> "bottles": 12, "variety": "Merlot"}
> newrow │ {"bottles": 132}
>
> --
> Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
> "La gente vulgar sólo piensa en pasar el tiempo;
> el que tiene talento, en aprovecharlo"
>
>
--
Yugo NAGATA
.
However, I think we would want a comment on the added line. Also, the
attached test should be placed in the regression test.
Regards,
Yugo Nagata
>
> [1] https://commitfest.postgresql.org/41/3641/
>
> --
> Antonin Houska
> Web: https://www.cybertec-postgresql.com
>
--
Yugo NAGATA
On Wed, 01 Feb 2023 11:47:23 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Antonin Houska wrote:
> >> While working on [1] I noticed that if RLS gets enabled, the COPY TO
> >> command
> >> includes the contents of child table into the result, although t
the commit make_etags on Mac failed anyway. Do we want make_etags to
> restore the previous behavior? i.e. 'etags' program not found
>
> >> If so, we should revert the changes of make_etags by the commit and
> >> make make_etags work with that ctags?
>
&
;--help" might be intended rather than "--version" to check
supported options? Even so, ctags would have other option whose name contains
"-e" than Emacs support, so this check could end in a wrong result. Therefore,
it seems to me that it is better to check immediately if e
Hi,
On Mon, 12 Sep 2022 17:03:43 +0200
Alvaro Herrera wrote:
> On 2022-Mar-28, Yugo NAGATA wrote:
>
> > On Fri, 25 Mar 2022 16:19:54 -0400
> > Tom Lane wrote:
>
> > > I am not convinced this is a great idea. The current behavior is that
> > > a statem
On Fri, 9 Sep 2022 16:27:45 +0530
Dilip Kumar wrote:
> On Tue, Jul 26, 2022 at 3:31 PM Richard Guo wrote:
> >
> >
> > On Tue, Jul 26, 2022 at 3:44 PM Yugo NAGATA wrote:
> >>
> >> If such two transactions run concurrently, a write skew anomaly occur
Hi,
On Tue, 9 Aug 2022 00:21:02 +0900
Yugo NAGATA wrote:
> On Wed, 27 Jul 2022 22:50:55 -0400
> Tom Lane wrote:
>
> > Yugo NAGATA writes:
> > > I've looked at the commited fix. What I wonder is whether a change in
> > > IsInTransactionBlock() is necess
_attr(equal_ignore);
In this case, pg_node_attr is mistakenly interpreted to be
the name of the field. So, I propose to use -I option of ctags
to ignore the marco name. Attached is a patch to do it.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/tools/make_ctags b/src/tools/make_ctags
Hello
On Mon, 10 Oct 2022 12:04:22 +0200
Alvaro Herrera wrote:
> Hello
>
> On 2022-Oct-07, Yugo NAGATA wrote:
>
> > I found that tag files generated by src/tools/make_ctags
> > doesn't include some keywords, that were field names of node
> > structs, for
gt; the links.
>
> Also I have changed make_etags so that it exec make_ctags, which seems
> to be the consensus.
Thank you for following up my patch.
I fixed the patch to allow use both -e and -n options together.
Regards,
Yugo Nagata
>
> Best reagards,
> --
> Tatsuo Is
Hello Micheal-san,
On Thu, 13 Oct 2022 17:02:06 +0900
Michael Paquier wrote:
> On Fri, Sep 30, 2022 at 10:12:13AM +0900, Yugo NAGATA wrote:
> > Thank you for comment. Do you think it can be marked as Ready for Commiter?
>
> Matviews have been discarded from needing predic
;s no objection.
I am fine with this patch.
By the way, in passing, how about adding "tags" and "TAGS" to
.gitignore file?
>
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
--
Yugo NAGATA
; > I fixed the patch to allow use both -e and -n options together.
> >>
> >> Thanks. I have made mostly cosmetic changes so that it is more
> >> consistent with existing scripts.
> >>
> >> I would like to push v6 patch if there's no objection.
> &
files?
> Best reagards,
> --
> Tatsuo Ishii
> SRA OSS LLC
> English: http://www.sraoss.co.jp/index_en/
> Japanese:http://www.sraoss.co.jp
--
Yugo NAGATA
tags -e) and it was
just for testing the patch. Similarly, someone who runs mistakenly this
command might want this option. However, as you say, there've been no
complain about this, so I don't feel it necessary so much. Maybe, users
of this command would be able to remove tags by their selves easily.
Regards,
Yugo Nagata
--
Yugo NAGATA
logAgg(thread->logfile, &aggs);
I think we don't have to call doLog() before logAgg(). If we call doLog(),
we will count an extra transaction that is not actually processed because
accumStats() is called in this.
Regards,
Yugo Nagata
--
Yugo NAGATA
t;seconds" to "us" using casting like
end_time = threads[0].create_time + (int64) 100 * duration;
or
next_report = last_report + (int64) 100 * progress;
Is there a reason use INT64CONST instead of (int64)? Do these imply the same
effect?
Sorry, if this is a dumb question...
Regards,
Yugo Nagata
--
Yugo NAGATA
this fix.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index dc84b7b9b7..1aa3e6b7be 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -3232,7 +3232,8 @@ advanceConnectionState(TState *thread, CState *st, StatsData
advanceConnectionState to threadRun and just
break the loop.
+ /* otherwise loop over
PREPARE_THROTTLE */
break;
I attached the fixed patch that uses return instead of break, and I confirmed
that this made the progress reporting work property.
lso fixed this in the attached patch.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index d7479925cb..1ec42a3ba2 100644
--- a/src/bin/pgbench/pgbench.c
+++ b/src/bin/pgbench/pgbench.c
@@ -3536,8 +3536,10 @@ advanceConnectionState(TState *thre
insane" parameters, as pg is unlikely to reach 100 million tps, ever.
> It seems to me enough that the command is not blocked in such cases.
Sure. The change from "break" to "return" is just for making the progress
reporting work in the loop, as you mentioned. However, my original intention
is avoiding stuck in a corner-case where a unrealistic parameter was used, and
I agree with you that this change is not so necessary for handling such a
special situation.
Regards,
Yugo Nagata
--
Yugo NAGATA
example like this.
@@ -6419,6 +6419,7 @@ main(int argc, char **argv)
initRandomState(&thread->ts_throttle_rs);
initRandomState(&thread->ts_sample_rs);
thread->logfile = NULL; /* filled in later */
+ thread->bench_start = 0;
thread->latency_late = 0;
initStats(&thread->stats, 0)
typo: faild -> failed
Regards,
Yugo Nagata
--
Yugo NAGATA
complete."
Otherwise, if we want pgbench to exit immediately when a connection error
occurs,
we have tocall exit(1) to ensure the exit code is 1, of course. Anyway, it is
wrong
that thecurrent pgbench exit successfully with exit code 0 when doConnnect
fails.
Regards,
Yugo Nagata
--
Yugo
ith this patch.
>
> I do not get it.
It was not a problem because --sampling-rate --aggregate-interval cannot be
used at the same time.
> > If I am following this code correctly, we don't care about accumStats()
> > in the code path of a thread we are done with, right?
On Tue, 15 Jun 2021 18:01:18 +0900
Michael Paquier wrote:
> On Tue, Jun 15, 2021 at 05:15:14PM +0900, Yugo NAGATA wrote:
> > On Tue, 15 Jun 2021 10:05:29 +0200 (CEST) Fabien COELHO
> > wrote:
> > It was not a problem because --sampling-rate --aggregate-interval cannot be
Assert(tx) instead of using "else if (tx)" because
we are assuming that tx is always true when agg_interval is not used, right?
--
Yugo NAGATA
issue from the originally proposed patch.
[1]
https://www.postgresql.org/message-id/flat/TYCPR01MB5870057375ACA8A73099C649F5349%40TYCPR01MB5870.jpnprd01.prod.outlook.com.
Regards,
Yugo Nagata
--
Yugo NAGATA
aybe
> reattempting connections would make also sense in such case.
This might become possible after pgbench gets the feature to retry in deadlock
or serialization errors. I am working on rebase of the patch [2] and I will
submit this in a few days.
[2]
https://www.postgresql.org/message-
On Mon, 14 Jun 2021 16:06:10 +0900
Yugo NAGATA wrote:
> On Mon, 14 Jun 2021 08:47:40 +0200 (CEST)
> Fabien COELHO wrote:
> > > I attached the fixed patch that uses return instead of break, and I
> > > confirmed
> > > that this made the progress reporting work
NIC[_RAW] is used,
clock_gettime doesn't return epoch time. Therefore, we can use
INSTR_TIME_SET_CURRENT aiming to calculate a duration, but we should
not have used this to get the current timestamp.
I think we can fix this issue by using gettimeofday for logging as before
this was changed. I
there is another advantage of using clock_gettime(). That is, this
returns precise results in nanoseconds. However, we can not benefit from it
because
pg_time_now() converts the value to uint64 by using INSTR_TIME_GET_MICROSEC. So,
if we would like more precious statistics in pgbench, it might be better
tion erros reported in this thread
will be fixed by the patch attached in my previous post (a major part are
written by you :-) ). Is this acceptable for you?
Regards,
Yugo Nagata
--
Yugo NAGATA
On Thu, 17 Jun 2021 14:17:56 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Thu, 17 Jun 2021 12:23:42 +0900, Yugo NAGATA wrote
> in
> > On Wed, 16 Jun 2021 21:11:41 +0200 (CEST)
> > Fabien COELHO wrote:
> > > I cannot say that I'm thrilled by having multiple
569784714 60 1398
1345828509 7073 1979779 573489941 236 1411
If we obey the document and keep the back-compatibility, we should fix
logAgg().
The attached patch includes these fixes.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index
if (thread->state[j].state != CSTATE_FINISHED)
+ exit_code = 2;
+
+ /* aggregate thread level stats */
Does this make sense?
--
Yugo NAGATA
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index d7479925cb..901f25aab7 100644
--- a/src/bin/pgbenc
> On second look, I think that error is fine, indeed we do not stop the
> process, so "fatal" it is not;
I replaced this 'fatal' with 'error' because we are aborting the client
instead of exit(1). When pgbench was rewritten to use common logging API
by the commit 30a3e772b40, somehow pg_log_fatal was used, but I am
wondering it should have be pg_log_error.
> Attached Yugo-san patch with some updates discussed in the previous mails,
> so as to move things along.
Thank you for update. I agree with this fix.
Regards,
Yugo Nagata
--
Yugo NAGATA
Hi hackers,
On Mon, 24 May 2021 11:29:10 +0900
Yugo NAGATA wrote:
> Hi hackers,
>
> On Tue, 10 Mar 2020 09:48:23 +1300
> Thomas Munro wrote:
>
> > On Tue, Mar 10, 2020 at 8:43 AM Fabien COELHO wrote:
> > > >> Thank you very much! I'm going
/commitfest.postgresql.org/33/3194/
Thanks!
--
Yugo NAGATA
; Documentation:not tested
>
> Looks fine to me, as a way of catching this edge case.
Thank you for looking into this!
'make installcheck-world' and 'Implements feature' are marked "failed",
but did you find any problem on this patch?
--
Yugo NAGATA
are nested "vars". Could this make a codereader confused?
> ## About comments
>
> Remove the comment on enlargeVariables about "It is assumed …" the issue
> of trying MAXINT vars is more than remote and is not worth mentioning. In
> the same function, remove the comments about MARGIN, it is already on the
> macro declaration, once is enough.
Sure. I'll remove them.
Regards,
Yugo Nagata
--
Yugo NAGATA
scussed in [1].
[1]
https://www.postgresql.org/message-id/alpine.DEB.2.22.394.2106181535400.3146194%40pseudo
I attached the updated patach.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index d7479925cb..9d2abbfb68 100644
--- a/src/bin/pgbe
On Wed, 30 Jun 2021 14:35:37 +0900
Yugo NAGATA wrote:
> Hello Asif,
>
> On Tue, 29 Jun 2021 13:21:54 +
> Asif Rehman wrote:
>
> > The following review has been posted through the commitfest application:
> > make installcheck-world: tested, passed
> >
Tests
>
> There are tests, good!
>
> I'm wondering whether something simpler could be devised to trigger
> serialization or deadlock errors, eg with a SEQUENCE and an \if.
>
> See the attached files for generating deadlocks reliably (start with 2
> clients).
> W
>of all transaction tries; more over, you cannot use an unlimited
> > number
>
> of all transaction tries; moreover, you cannot use an unlimited number
>
Thanks. I'll fix.
Regards,
Yugo Nagata
--
Yugo NAGATA
don't want to print the number of transactions failed due to -T, we can
fix to forbid to use -T without latency-limit under max-tries=0 for avoiding
possible never-ending-benchmark. In this case, users have to limit the number of
transaction retry by specifying latency-limit or max-tries (>0). However, if
some
users would like to benchmark simply allowing unlimited retries, using -T and
max-tries=0 seems the most straight way, so I think it is better that they can
be
used together.
Regards,
Yugo Nagata
--
Yugo NAGATA
ding on your perosnal assumption.
Ok. If we regard that a transaction is still running even when it is under
retrying after an error, terminate of the retry may imply to terminate running
the transaction forcibly.
> I still don't understand why you think that --max-tries non 0 case
> will *certainly* finish in finite time whereas --max-tries=0 case will
> not.
I just mean that --max-tries greater than zero will prevent pgbench from
retrying a
transaction forever.
Regards,
Yugo Nagata
--
Yugo NAGATA
te running
> benchmarking. Remember, pgbench is a tool for serious users, not for
> novice users.
Of course, users themselves should be careful of problematic script, but it
would be better that pgbench itself avoids problems if pgbench can beforehand.
> Or, we should terminate the last cycle of benchmark regardless it is
> retrying or not if -T expires. This will make pgbench behaves much
> more consistent.
Hmmm, indeed this might make the behaviour a bit consistent, but I am not
sure such behavioural change benefit users.
Regards,
Yugo Nagata
--
Yugo NAGATA
/Deadlock Retries" section a bit to
emphasis that such errors are treated differently than other errors.
> >> See the attached files for generating deadlocks reliably (start with 2
> >> clients). What do you think? The PL/pgSQL minimal, it is really
> >> clien
citly prevent such writes operations
on large object in read-only transactions, like:
postgres=# SELECT lo_create(42);
ERROR: cannot execute lo_create in a read-only transaction
The patch is attached.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/libpq/be-fsstubs.c b/src/backend/
uot;,
but it is just because the foreign table has no handler,
not due to TRUNCATE.
The patch is attached.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/test/regress/expected/foreign_data.out b/src/test/regress/expected/foreign_data.out
index 5bf03680d2..33505352cc 100644
--- a/src/t
On Sat, 28 May 2022 18:00:54 +0900
Michael Paquier wrote:
> On Fri, May 27, 2022 at 03:30:28PM +0900, Yugo NAGATA wrote:
> > Currently, lo_creat(e), lo_import, lo_unlink, lowrite, lo_put,
> > and lo_from_bytea are allowed even in read-only transactions.
> > By using the
nd done as of 0efa513.
Thank you!
--
Yugo NAGATA
functions in read-only context.
I also fixed to raise the error in each of lo_truncate and lo_truncate64
per Michael's comment in the other post.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/libpq/be-fsstubs.c b/src/backend/libpq/be-fsstubs.c
index 5804532881..19c0a0c5de 1006
--- INV_WRITE = 0x4
> +-- INV_READ = 0x4
> +-- INV_WRITE = 0x2
> Good catch! This one is kind of independent, so I have fixed it
> separately, in all the expected output files.
Thanks!
--
Yugo NAGATA
diff --git a/doc/src/sgml/lobj.sgml b/doc/src/sgml/lobj.sgml
ot; occurs. So, what
about adding a test this message output? We can add this test
for file_fdw because it is one of the such foreign data wrappers.
I attached a patch.
[1] https://postgr.es/m/20220527172543.0a2fdb469cf048b81c096...@sraoss.co.jp
--
Yugo NAGATA
diff --git a/contrib/file_fdw/exp
Hello,
I propose supporting TRUNCATE triggers on foreign tables
because some FDW now supports TRUNCATE. I think such triggers
are useful for audit logging or for preventing undesired
truncate.
Patch attached.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/contrib/postgres_fdw/expected
On Mon, 4 Jul 2022 15:51:32 +0900
Michael Paquier wrote:
> On Wed, Jun 29, 2022 at 05:29:50PM +0900, Yugo NAGATA wrote:
> > Thank you for reviewing the patch. I attached the updated patch.
>
> Thanks for the new version. I have looked at that again, and the set
> of
On Fri, 08 Jul 2022 09:44:10 +0900 (JST)
Kyotaro Horiguchi wrote:
> At Fri, 8 Jul 2022 01:06:18 +0900, Fujii Masao
> wrote in
> >
> >
> > On 2022/07/08 0:33, Tom Lane wrote:
> > > Fujii Masao writes:
> > >> On 2022/06/30 10:48, Yugo NAGATA wr
Hello Fujii-san,
Thank you for reviewing the patch!
On Fri, 8 Jul 2022 00:54:37 +0900
Fujii Masao wrote:
>
>
> On 2022/06/30 19:38, Yugo NAGATA wrote:
> > Hello,
> >
> > I propose supporting TRUNCATE triggers on foreign tables
> > because some FDW no
On Fri, 8 Jul 2022 16:50:10 +0900
Ian Lawrence Barwick wrote:
> 2022年7月8日(金) 14:06 Fujii Masao :
> > On 2022/07/08 11:19, Yugo NAGATA wrote:
> > >> You added "foreign tables" for BEFORE statement-level trigger as the
> > >> above, but ISTM that yo
ULL
Heap Blocks: exact=1
-> BitmapOr (cost=133.86..133.86 rows=1 width=0) (actual
time=0.091..0.093 rows=0 loops=1)
-> Bitmap Index Scan on mv_index (cost=0.00..4.43 rows=1
width=0) (actual time=0.065..0.065 rows=1 loops=1)
Index Cond: (id = diff.id)
-> Bitmap Index Scan on mv_index (cost=0.00..4.43 rows=1
width=0) (actual time=0.021..0.021 rows=0 loops=1)
Index Cond: (id IS NULL)
Planning Time: 0.666 ms
Execution Time: 0.399 ms
(15 rows)
Regards,
Yugo Nagata
--
Yugo NAGATA
Fujii Masao
> Advanced Computing Technology Center
> Research and Development Headquarters
> NTT DATA CORPORATION
--
Yugo NAGATA
he patch.
>
> Pushed. Thanks!
Thanks!
>
> Regards,
>
> --
> Fujii Masao
> Advanced Computing Technology Center
> Research and Development Headquarters
> NTT DATA CORPORATION
--
Yugo NAGATA
gular tables and acquire predicate
locks on materialized views as well.
What do you think about it?
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c
index 5136da6ea3..6d414bfcc9 100644
--- a/src/backend/storage/lmgr/pre
t;including connections establishing"
and "excluding connections establishing" regardless with -C, so we should
measure delays in the same way.
I updated the patch for pg13 to measure disconnection delay when -C is not
specified. I attached the updated patch for pg13 as well as one
cording to the patch tester, the patch does not apply.
Well, that's because both the patch for PG14 and one for PG13
are discussed here.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
>
>
--
Yugo NAGATA
Hello Fujii-san,
On Mon, 30 Aug 2021 23:36:30 +0900
Fujii Masao wrote:
>
>
> On 2021/08/26 12:13, Yugo NAGATA wrote:
> > Ok. That makes sense. The output reports "including connections
> > establishing"
> > and "excluding connections establishing&quo
s trying to measure connection overhead which
> naturally includes disconnection overhead.
I think it is better to measure disconnection delays when -C is specified in
pg 14. This seems not necessary when -C is not specified because pgbench just
reports "initial connection time".
How
we should also change the
> > behavior of pg13 or later? If so, should we measure disconnection delay even
> > when -C is not specified in pg13?
>
> You mean "pg13 or before"?
Sorry, you are right. I mean "pg13 or before".
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
--
Yugo NAGATA
t; even
> >> > when -C is not specified in pg13?
> >>
> >> You mean "pg13 or before"?
> >
> > Sorry, you are right. I mean "pg13 or before".
>
> I would think we should leave as it is for pg13 and before to not surprise
> user
dified the comment slightly and ran pgindent. Barring any
> > objection,
> > I will commit this patch only in master and v14.
>
> Pushed. Thanks!
Thank you!
--
Yugo NAGATA
(saving some
> indentation).
Yes. I'll fix.
> + check_stack_depth();
> +
> + if (node == NULL)
> + return false;
>
> It seems the node check can be placed ahead of the stack depth check.
OK.
> + * CreateindexOnIMMV
>
> CreateindexOnIMMV ->
ns (__ivm_count__ etc.), and in
the opposite case, we need to create them again. The former (IMMV->IVM) might be
easer, but for the latter (IVM->IMMV) I wonder we would need to re-create IMMV.
Regards,
Yugo Nagata
--
Yugo NAGATA
pg_dump, following error occurs.
>
> ERROR: ALTER action ADD CONSTRAINT cannot be performed on relation "ivm_t"
> DETAIL: This operation is not supported for materialized views.
Good catch! It was my mistake creating unique constraints on IMMV in spite of
we cannot defined them via SQL. I'll fix it to use unique indexes instead of
constraints.
Regards,
Yugo Nagata
--
Yugo NAGATA
Hi hackers,
I attached the updated patch including fixes reported by
Zhihong Yu and Ryohei Takahashi.
Regards,
Yugo Nagata
On Wed, 22 Sep 2021 19:12:27 +0900
Yugo NAGATA wrote:
> Hello Takahashi-san,
>
> On Mon, 6 Sep 2021 10:06:37 +
> "r.takahash...@fujitsu.com&q
Hello Fujii-san,
On Tue, 7 Sep 2021 02:34:17 +0900
Fujii Masao wrote:
> On 2021/07/29 13:23, Yugo NAGATA wrote:
> > Hello,
> >
> > On Fri, 18 Jun 2021 15:58:48 +0200 (CEST)
> > Fabien COELHO wrote:
> >
> >> Attached Yugo-san patch with some updates d
de. There is a mention about libpq
supporting pipeline, so I think we can also mention that of pgbench.
There are other minor improvement on pgbench, but pgbench is just a
benchnark tool and its changes do not directly affect to user application,
so maybe we don't have to describe all in the release notes.
Regards,
Yugo Nagata
--
Yugo NAGATA
Hello Takahashi-san,
On Wed, 22 Sep 2021 18:53:43 +0900
Yugo NAGATA wrote:
> Hello Takahashi-san,
>
> On Thu, 5 Aug 2021 08:53:47 +
> "r.takahash...@fujitsu.com" wrote:
>
> > Hi Nagata-san,
> >
> >
> > Thank you for your reply.
> >
d, we need to call
PQflush until it returns 0, as documented with regard to PQflush.
Do we need to fix the description of PQsetnonblocking?
Regards,
Yugo Nagata
--
Yugo NAGATA
g by the -T option is, I guess it
just
complained about reporting the termination of retrying as failures. Therefore,
I will fix to finish the benchmark when the time is over during retrying, that
is,
change the state to CSTATE_FINISHED instead of CSTATE_ERROR in such cases.
Regards,
Yugo Nagata
--
Yugo NAGATA
ther the problem is that retrying transaction is terminated by -T
option, or that pgbench reports it as the number of failed transactions? But
now, I understood this is the latter that you don't want to count the temination
of retrying as failures. Thanks.
Regards,
Yugo Nagata
--
Yugo NAGATA
Hello,
I attached the updated patch.
On Tue, 13 Jul 2021 15:50:52 +0900
Yugo NAGATA wrote:
> > >> > I'm a little hesitant about how to count and report such unfinished
> > >> > because of bench timeout transactions, though. Not counting them seems
> >
efore, noting in the documentation that the first command in a
pipeline
starts an implicit transaction might be useful for users.
What do you think?
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c
index 364b5a2e47..56e790fa33 100644
--- a
ad of header corruption
itself,
I wander that we could check just xlp_pageaddr instead of calling
XLogReaderValidatePageHeader.
Regards,
Yugo Nagata
--
Yugo NAGATA
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index edb15fe58d..4fdb23f061 100644
--- a/src
On Sat, 17 Jul 2021 18:40:02 -0300
Ranier Vilela wrote:
> Em sáb., 17 de jul. de 2021 às 16:57, Yugo NAGATA
> escreveu:
>
> > Hello,
> >
> > I found that any corruption of WAL page header found during recovery is
> > never
> > reported in log messag
On Wed, 14 Jul 2021 21:22:37 +0530
vignesh C wrote:
> On Mon, May 17, 2021 at 10:08 AM Yugo NAGATA wrote:
> >
> > On Fri, 7 May 2021 14:14:16 +0900
> > Yugo NAGATA wrote:
> >
> > > On Mon, 26 Apr 2021 16:03:48 +0900
> > > Yugo NAGATA wrote:
>
ecause the connection may not be established in the
CSTATE_CHOOSE_SCRIPT state.
> In comments: not yet -> needed.
Thanks. I'll fix it.
Regards,
Yugo Nagata
--
Yugo NAGATA
On Mon, 19 Jul 2021 15:14:41 +0900 (JST)
Kyotaro Horiguchi wrote:
> Hello.
>
> At Sun, 18 Jul 2021 04:55:05 +0900, Yugo NAGATA wrote
> in
> > Hello,
> >
> > I found that any corruption of WAL page header found during recovery is
> > never
> > repor
201 - 300 of 645 matches
Mail list logo
