> Nathan Bossart writes:
>> On Fri, Feb 07, 2025 at 01:10:04PM -0500, Tom Lane wrote:
>>> My thought was that duplicating the logic isn't so bad, as attached.
>
>> WFM!
>
> It does fix the problem here, so I'll make it so.
Sorry for the problem and thank you for the fix!
--
Tatsuo Ishii
SRA OSS
Nathan Bossart writes:
> On Fri, Feb 07, 2025 at 01:10:04PM -0500, Tom Lane wrote:
>> My thought was that duplicating the logic isn't so bad, as attached.
> WFM!
It does fix the problem here, so I'll make it so.
regards, tom lane
On Fri, Feb 07, 2025 at 01:10:04PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> Oops, I was already taking a look at this. I figured it'd just be
>> something like the following, although maybe there's a more elegant way.
>
> Well, the stuff with prev_chars really ought to be skipped as we
Hi,
On 2025-02-07 12:58:38 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I just did pgbench -i 100 -q via ssh and noticed it was *way* slower than I
> > expected. Did it with debian's pgbench, no such issue.
>
> > It's due to this patch.
>
> Oh! The problem is that the hunk
>
> +
Nathan Bossart writes:
> On Fri, Feb 07, 2025 at 12:58:38PM -0500, Tom Lane wrote:
>> Let me have a go at fixing it, and if it turns out to be harder
>> than I think, I'll revert it instead.
> Oops, I was already taking a look at this. I figured it'd just be
> something like the following, altho
On Fri, Feb 07, 2025 at 12:58:38PM -0500, Tom Lane wrote:
> Let me have a go at fixing it, and if it turns out to be harder
> than I think, I'll revert it instead.
Oops, I was already taking a look at this. I figured it'd just be
something like the following, although maybe there's a more elegant
Andres Freund writes:
> I just did pgbench -i 100 -q via ssh and noticed it was *way* slower than I
> expected. Did it with debian's pgbench, no such issue.
> It's due to this patch.
Oh! The problem is that the hunk
+ /*
+* If the previous progress message is longer than the cur
On Fri, Feb 07, 2025 at 12:28:16PM -0500, Andres Freund wrote:
> I just did pgbench -i 100 -q via ssh and noticed it was *way* slower than I
> expected. Did it with debian's pgbench, no such issue.
>
> It's due to this patch.
>
> /srv/dev/build/m-opt/src/bin/pgbench/pgbench -i -s 10 -Idtg -h /tm
Hi,
On 2024-11-26 01:32:10 +0900, Fujii Masao wrote:
> On 2024/11/25 8:31, Tatsuo Ishii wrote:
> > Now that two minor releases are out, are you going to commit and
> > back-patch this?
>
> Yes, I will.
>
> But, the patch didn't apply cleanly to some back branches, so I've created
> and attached up
On Thu, Nov 28, 2024 at 07:45:09AM +0900, Tatsuo Ishii wrote:
> Yeah, maybe git apply is not smart enough.
`git apply` is more picky than a simple `patch -p1` as it checks more
context around the patch and is more likely to reject some input.
When the former does not work correctly, I personally j
>> Sure. The patch for master to v15 look good to me. Unfortunately
>> v5-0001-pgbench-Ensure-previous-progress-message-is-fully-pg13-14.patch
>> applies to v14 but does not apply to v13.
>> $ git checkout REL_13_STABLE
>> Switched to branch 'REL_13_STABLE'
>> Your branch is up to date with 'origi
On 2024/11/27 18:41, Tatsuo Ishii wrote:
Yes, I will.
But, the patch didn't apply cleanly to some back branches, so I've
created
and attached updated patches for them. Could you review these?
If they look good, I'll proceed with pushing them.
Sure. The patch for master to v15 look good to m
> Yes, I will.
>
> But, the patch didn't apply cleanly to some back branches, so I've
> created
> and attached updated patches for them. Could you review these?
> If they look good, I'll proceed with pushing them.
Sure. The patch for master to v15 look good to me. Unfortunately
v5-0001-pgbench-E
On 2024/11/25 8:31, Tatsuo Ishii wrote:
Now that two minor releases are out, are you going to commit and
back-patch this?
Yes, I will.
But, the patch didn't apply cleanly to some back branches, so I've created
and attached updated patches for them. Could you review these?
If they look good,
Hi Fujii-san,
> On 2024/11/08 11:47, Tatsuo Ishii wrote:
>> I think you need to adjust
>> fprintf(stderr, "%*c\r", chars - 1, ' '); /* Clear the current
>> line */
>> to:
>> fprintf(stderr, "%*c\r", chars, ' '); /* Clear the current
>> line */
>> since now chars does
> On 2024/11/08 11:47, Tatsuo Ishii wrote:
>> I think you need to adjust
>> fprintf(stderr, "%*c\r", chars - 1, ' '); /* Clear the current
>> line */
>> to:
>> fprintf(stderr, "%*c\r", chars, ' '); /* Clear the current
>> line */
>> since now chars does not consider th
On 2024/11/08 11:47, Tatsuo Ishii wrote:
I think you need to adjust
fprintf(stderr, "%*c\r", chars - 1, ' '); /* Clear the
current line */
to:
fprintf(stderr, "%*c\r", chars, ' '); /* Clear the current line
*/
since now chars does not consider the EOL c
>> Maybe. But I am also worried about the case when we would want to
>> change the log line format in the future. We might introduce this kind
>> of bug again. By dynamically calculating the number of necessary
>> spaces, we don't need to think about the concern.
>
> +1
>
> +
On 2024/11/07 10:41, Tatsuo Ishii wrote:
The patch works perfectly for the case that there is one extra brace
as shown in your example. However I think it will not work if there
are two or more extra braces.
Are you suggesting adding more space characters before the carriage
return
in the pro
>>> The patch works perfectly for the case that there is one extra brace
>>> as shown in your example. However I think it will not work if there
>>> are two or more extra braces.
>>
>> Are you suggesting adding more space characters before the carriage
>> return
>> in the progress reporting line,
>> The patch works perfectly for the case that there is one extra brace
>> as shown in your example. However I think it will not work if there
>> are two or more extra braces.
>
> Are you suggesting adding more space characters before the carriage
> return
> in the progress reporting line, like th
On 2024/11/02 20:43, Tatsuo Ishii wrote:
Hi,
I noticed an issue in the pgbench progress message where an extra
closing parenthesis )) appears, as shown below:
700 of 1000 tuples (70%) of pgbench_accounts done (elapsed
19.75 s, remaining 8.46 s))
Yeah, annoying.
This occurs when r
> Hi,
>
> I noticed an issue in the pgbench progress message where an extra
> closing parenthesis )) appears, as shown below:
>
> 700 of 1000 tuples (70%) of pgbench_accounts done (elapsed
> 19.75 s, remaining 8.46 s))
Yeah, annoying.
> This occurs when running commands like pgbench -i
Hi,
I noticed an issue in the pgbench progress message where an extra
closing parenthesis )) appears, as shown below:
700 of 1000 tuples (70%) of pgbench_accounts done (elapsed 19.75
s, remaining 8.46 s))
This occurs when running commands like pgbench -i -s100 and is caused by
left
24 matches
Mail list logo
