On Tue, 2 Nov 2021 23:11:39 +0900
Fujii Masao wrote:
>
>
> On 2021/11/01 23:01, Fujii Masao wrote:
> >> The remainings are the changes of handling of initial connection or
> >> logfile open failures. I agree to push them at least for the master.
> >> But I'm not sure if they should be back-patc
On 2021/11/01 23:01, Fujii Masao wrote:
The remainings are the changes of handling of initial connection or
logfile open failures. I agree to push them at least for the master.
But I'm not sure if they should be back-patched. Without these changes,
even when those failures happen, pgbench proc
On 2021/10/09 0:41, Fujii Masao wrote:
On 2021/10/01 15:27, Michael Paquier wrote:
On Wed, Sep 29, 2021 at 10:11:53PM +0900, Fujii Masao wrote:
BTW, when logfile fails to be opened, pgbench gets stuck due to commit
aeb57af8e6. So even if we decided not to back-patch those changes,
we shoul
On 2021/09/29 22:11, Fujii Masao wrote:
On 2021/09/24 11:26, Fujii Masao wrote:
On 2021/09/24 7:26, Yugo NAGATA wrote:
That makes sense. Failures of setup connection or initial connection doesn't
seem 'static problems'. I rewrote this description to explain exit status 1
indicates also in
On 2021/10/01 15:27, Michael Paquier wrote:
On Wed, Sep 29, 2021 at 10:11:53PM +0900, Fujii Masao wrote:
BTW, when logfile fails to be opened, pgbench gets stuck due to commit
aeb57af8e6. So even if we decided not to back-patch those changes,
we should improve the handling of logfile open fail
On Wed, Sep 29, 2021 at 10:11:53PM +0900, Fujii Masao wrote:
> BTW, when logfile fails to be opened, pgbench gets stuck due to commit
> aeb57af8e6. So even if we decided not to back-patch those changes,
> we should improve the handling of logfile open failure, to fix the issue.
There is an entry i
On 2021/09/24 11:26, Fujii Masao wrote:
On 2021/09/24 7:26, Yugo NAGATA wrote:
That makes sense. Failures of setup connection or initial connection doesn't
seem 'static problems'. I rewrote this description to explain exit status 1
indicates also interal errors and early errors.
Exit st
On 2021/09/24 7:26, Yugo NAGATA wrote:
That makes sense. Failures of setup connection or initial connection doesn't
seem 'static problems'. I rewrote this description to explain exit status 1
indicates also interal errors and early errors.
Exit status 1 indicates static problems such as in
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 discussed in the previous mails,
> >> so as
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 discussed in the previous mails,
so as to move things along.
I attached the patch rebased to a change due to 856de3b39cf.
+
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 --git a/s
Hello Horiguchi-san, Fabien,
On Fri, 18 Jun 2021 15:58:48 +0200 (CEST)
Fabien COELHO wrote:
>
> >>>/* must be something wrong */
> >>>pg_log_error("%s() failed: %m", SOCKET_WAIT_METHOD);
> >>>goto done;
> >>
> >> Should say such like "thread %d aborted: %s() failed: ...
/* must be something wrong */
pg_log_error("%s() failed: %m", SOCKET_WAIT_METHOD);
goto done;
Should say such like "thread %d aborted: %s() failed: ...".
After having a lookg, there are already plenty such cases. I'd say not to
change anything for beta, and think of it
Hello,
Doing this means we regard any state other than CSTATE_FINISHED as
aborted. So, the current goto's to done in threadRun are effectively
aborting a part or the all clients running on the thread. So for
example the following place:
pgbench.c:6713
/* must be something wrong */
At Thu, 17 Jun 2021 11:52:04 +0200 (CEST), Fabien COELHO
wrote in
> > Ok. I gave up to change the state in threadRun. Instead, I changed the
> > condition at the end of bench, which enables to report abortion due to
> > socket errors.
> >
> > +@@ -6480,7 +6490,7 @@ main(int argc, char **argv)
>
Second, currently the *only* function to change the client state is
advanceConnectionState, so it can be checked there and any bug is only
there. We had issues before when several functions where doing updates,
and it was a mess to understand what was going on. I really want that it
stays that
Hello Fabien,
On Thu, 17 Jun 2021 10:37:05 +0200 (CEST)
Fabien COELHO wrote:
> > ). Is this acceptable for you?
>
> I disagree on two counts:
>
> First, thread[0] should not appear.
>
> Second, currently the *only* function to change the client state is
> advanceConnectionState, so it can b
Hello Yugo-san,
By the way, the issue of inital connection erros reported in this thread
will be fixed by the patch attached in my previous post (a major part are
written by you :-)
That does not, on its own, ensure that it is bug free:-)
). Is this acceptable for you?
I disagree on two
On Wed, 16 Jun 2021 20:25:31 +0200 (CEST)
Fabien COELHO wrote:
>
> Hello Yugo-san,
>
> >> When connection break while the bench has already started,
> >> maybe it makes more sense to proceed,
> >
> > The result would be incomplete also in this case. However, the reason why
> > it is worth to pr
Hello Yugo-san,
When connection break while the bench has already started,
maybe it makes more sense to proceed,
The result would be incomplete also in this case. However, the reason why
it is worth to proceed is that such information is still useful for users,
or we don't want to waste the
Hello Fabien,
On Mon, 14 Jun 2021 11:30:14 +0200 (CEST)
Fabien COELHO wrote:
> >>> Hmmm. Possibly. Another option could be not to report anything after some
> >>> errors. I'm not sure, because it would depend on the use case. I guess the
> >>> command returned an error status as well.
> >>
> >>
Hmmm. Possibly. Another option could be not to report anything after some
errors. I'm not sure, because it would depend on the use case. I guess the
command returned an error status as well.
I did not know any use cases and decisions , but I vote to report nothing when
error occurs.
I woul
On Mon, 14 Jun 2021 00:42:12 +
"kuroda.hay...@fujitsu.com" wrote:
> Dear Fabien,
>
> Thank you for replying!
>
> > Hmmm. Possibly. Another option could be not to report anything after some
> > errors. I'm not sure, because it would depend on the use case. I guess the
> > command returned
Hello Kuroda-san,
On Fri, 11 Jun 2021 08:58:45 +
"kuroda.hay...@fujitsu.com" wrote:
> Hi Hackers,
>
> I played pgbench with wrong parameters, and I found bug-candidate.
> The latest commit in my source is 3a09d75.
>
> 1. Do initdb and start.
> 2. Initialize schema and data with "scale fact
Dear Fabien,
Thank you for replying!
> Hmmm. Possibly. Another option could be not to report anything after some
> errors. I'm not sure, because it would depend on the use case. I guess the
> command returned an error status as well.
I did not know any use cases and decisions , but I vote to r
Hello Hayato-san,
I played pgbench with wrong parameters,
That's good:-)
and I found bug-candidate.
1. Do initdb and start.
2. Initialize schema and data with "scale factor" = 1.
3. execute following command many times:
$ pgbench -c 101 -j 10 postgres
Then, sometimes the negative " ini
26 matches
Mail list logo
