From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | masao(dot)fujii(at)oss(dot)nttdata(dot)com |
Cc: | btogiwarayuushi(at)oss(dot)nttdata(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fix for Extra Parenthesis in pgbench progress message |
Date: | 2024-11-08 02:47:13 |
Message-ID: | 20241108.114713.484828673471024549.ishii@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> 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
>
> + if (previous_chars != 0)
> + {
> + int n_spaces = chars - previous_chars;
> + fprintf(stderr, "%*s", n_spaces, "");
> + chars += n_spaces;
> + }
>
> Currently, this is added only when use_quiet is false, but shouldn’t
> it also apply when use_quiet is true?
Yes. The patch just showed my idea and I thought I needed to apply the
case when use_quiet is true. But the fix should be applied to after
"else if (use_quiet && (j % 100 == 0))" as shown in your patch.
> Also, what happens if chars is smaller than previous_chars?
My oversight. Better to check if chars is smaller than previous_chars.
> I’m unsure why chars needs to be incremented by n_spaces.
Yeah, it's not necessary.
> I’ve created an updated patch based on your idea―could you take a
> look?
Sure.
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 char. By clearing chars - 1,
the closing parenthesis will be left on the screen.
Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2024-11-08 03:05:38 | Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber |
Previous Message | Richard Guo | 2024-11-08 02:45:44 | Re: Inconsistent RestrictInfo serial numbers |