Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint
Дата
Msg-id CAMkU=1zVisFuD-O4WSe8fUcA1gE3b0DewzgKYT7kTk7TZehYKw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: gitlab post-mortem: pg_basebackup waiting for checkpoint  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
On Sun, Feb 26, 2017 at 12:32 PM, Magnus Hagander <magnus@hagander.net> wrote:

On Sun, Feb 26, 2017 at 8:27 PM, Michael Banck <michael.banck@credativ.de> wrote:
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.

Cheers,

Jeff

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Poor memory context performance in large hash joins
Следующее
От: Dave Cramer
Дата:
Сообщение: Re: [JDBC] [HACKERS] PGSERVICEFILE as a connection string parameter