From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Martin Marques <martin(dot)marques(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_basebackup --progress output for batch execution |
Date: | 2017-11-09 23:55:36 |
Message-ID: | CAMkU=1z=nSWx4P=p=YOOEe9EPmQeNkUOANFY+3LRYQcsr91W2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 29, 2017 at 4:00 PM, Martin Marques <
martin(dot)marques(at)2ndquadrant(dot)com> wrote:
> Hi,
>
> Some time ago I had to work on a system where I was cloning a standby
> using pg_basebackup, that didn't have screen or tmux. For that reason I
> redirected the output to a file and ran it with nohup.
>
> I normally (always actually ;) ) run pg_basebackup with --progress and
> --verbose so I can follow how much has been done. When done on a tty you
> get a nice progress bar with the percentage that has been cloned.
>
> The problem came with the execution and redirection of the output, as
> the --progress option will write a *very* long line!
>
> Back then I thought of writing a patch (actually someone suggested I do
> so) to add a --batch-mode option which would change the behavior
> pg_basebackup has when printing the output messages.
>
While separate lines in the output file is better than one very long line,
it still doesn't seem so useful. If you aren't watching it in real time,
then you really need to have a timestamp on each line so that you can
interpret the output. The lines are about one second apart, but I don't
know robust that timing is under all conditions.
I think I agree with Arthur that I'd rather have the decision made by
inspecting whether output is going to a tty, rather than by adding another
command line option. But maybe that is not detected robustly enough across
all platforms and circumstances?
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-11-10 00:02:17 | Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple |
Previous Message | Joe Conway | 2017-11-09 23:19:12 | Re: libpq connection strings: control over the cipher suites? |