Hi, Am Dienstag, den 14.02.2017, 18:18 -0500 schrieb Robert Haas: > On Tue, Feb 14, 2017 at 4:06 PM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: > > I'd rather have a --quiet mode instead. If you're running it by hand, > > you're likely to omit the switch, whereas when writing the cron job > > you're going to notice lack of switch even before you let the job run > > once. > > Well, that might've been a better way to design it, but changing it > now would break backward compatibility and I'm not really sure that's > a good idea. Even if it is, it's a separate concern from whether or > not in the less-quiet mode we should point out that we're waiting for > a checkpoint on the server side.
ISTM the consensus is that there should be no output in regular mode, but a message should be displayed in verbose and progress mode.
So I went forth and also added a message in progress mode (unless verbose messages are requested anyway).
Regarding the documentation, I tried to clarify the difference between the checkpoint types a bit more, but I think any further action is probably a larger rewrite of the documentation on this topic.
So attached are two patches, I've split it up in the documentation and the code output part. I'll add it as one commitfest entry in the "Clients" section though, as it's not really a big patch, unless somebody thinks it should have a secon entry in "Documentation"?
Agreed, and applied as one patch. Except I noticed you also fixed a couple of entries which were missing the progname in the messages -- I broke those out to a separate patch instead.
Made a small change to "using as much I/O as available" rather than "as possible", which I think is a better wording, along with the change of the idle wording I suggested before. (but feel free to point it out to me if that's wrong).
Should the below fprintf end in a \r rather than a \n, so that the the progress message gets over-written once the checkpoint is done and we have moved on?
if (showprogress && !verbose)
fprintf(stderr, "waiting for checkpoint\n");
That would seem more in keeping with how the other progress messages operate.
Agreed, that makes more sense. I've pushed a patch that does this.
