On Wed, Dec 4, 2019 at 11:35 AM Michael Paquier wrote:
>
> On Tue, Dec 03, 2019 at 10:30:35AM +0900, Amit Langote wrote:
> > How about adding a function, say print_progress_to_stderr(const char
> > *fmt,...), exposed to the front-end utilities and use it from
> > everywhere? Needless to say that i
On Tue, Dec 03, 2019 at 10:30:35AM +0900, Amit Langote wrote:
> How about adding a function, say print_progress_to_stderr(const char
> *fmt,...), exposed to the front-end utilities and use it from
> everywhere? Needless to say that it will contain the check for whether
> stderr points to terminal o
Attached v4.
Patch applies cleanly, compiles, works for me. Put it back to ready.
--
Fabien.
Thanks for the review.
On Mon, Dec 2, 2019 at 3:28 PM Michael Paquier wrote:
> On Mon, Dec 02, 2019 at 02:30:47PM +0900, Amit Langote wrote:
> > On Sun, Dec 1, 2019 at 4:33 AM Fabien COELHO wrote:
> >> Patch applies, compiles, works for me. No further comments.
> >>
> >> I switched the patch as
Another question I have is why doing only that for the data
initialization phase? Wouldn't it make sense to be consistent with the
other tools having --progress and do the same dance in pgbench's
printProgressReport()?
I thought of it but did not suggest it.
When running a bench I like se
On Mon, Dec 02, 2019 at 02:30:47PM +0900, Amit Langote wrote:
> On Sun, Dec 1, 2019 at 4:33 AM Fabien COELHO wrote:
>> Patch applies, compiles, works for me. No further comments.
>>
>> I switched the patch as ready.
>
> Thanks a lot.
An issue with the patch as proposed is that its style is diffe
Hi Fabien,
On Sun, Dec 1, 2019 at 4:33 AM Fabien COELHO wrote:
> Patch applies, compiles, works for me. No further comments.
>
> I switched the patch as ready.
Thanks a lot.
Regards,
Amit
I wrote the v1 patch on CentOS Linux, and now on MacOS. It would be
great if someone can volunteer to test on Windows terminal.
I do not have that.
Attached v3.
Patch applies, compiles, works for me. No further comments.
I switched the patch as ready.
--
Fabien.
Hi Fabien,
Thanks for taking a look again.
On Sat, Nov 30, 2019 at 4:28 PM Fabien COELHO wrote:
> > I have updated the patch based on these observations. Attached v2.
>
> Patch v2 applies & compiles cleanly, works for me.
>
> I'm not partial to Hungarian notation conventions, which is not widel
Hello Amit,
I have updated the patch based on these observations. Attached v2.
Patch v2 applies & compiles cleanly, works for me.
I'm not partial to Hungarian notation conventions, which is not widely
used elsewhere in pg. I'd suggest eolchar -> eol or line_end or whatever,
but others ma
Hi Fabien,
On Fri, Nov 29, 2019 at 10:13 PM Fabien COELHO wrote:
> > I wonder why we don't use the same style for $subject as pg_basebackup
> > --progress, that is, use a carriage return instead of a newline after
> > each line reporting the number of tuples copied?
>
> Patch applies cleanly, com
I wonder why we don't use the same style for $subject as pg_basebackup
--progress, that is, use a carriage return instead of a newline after
each line reporting the number of tuples copied?
Patch applies cleanly, compiles, and works for me.
My 0.02€:
fprintf -> fputs or fputc to avoid a form
Hi Fabien,
On Thu, Nov 28, 2019 at 4:35 PM Fabien COELHO wrote:
>
>
> Hello Amit,
>
> > I wonder why we don't use the same style for $subject as pg_basebackup
> > --progress, that is, use a carriage return instead of a newline after
> > each line reporting the number of tuples copied?
>
> Why not
Hello Amit,
I wonder why we don't use the same style for $subject as pg_basebackup
--progress, that is, use a carriage return instead of a newline after
each line reporting the number of tuples copied?
Why not.
Attached patch for that.
I'll look into it. Could you add it to the CF app?
On Thu, Nov 28, 2019 at 10:41:14AM +0900, Amit Langote wrote:
> I wonder why we don't use the same style for $subject as pg_basebackup
> --progress, that is, use a carriage return instead of a newline after
> each line reporting the number of tuples copied?
>
> Attached patch for that.
I have not
15 matches
Mail list logo
