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

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint
Дата
Msg-id CABUevEyAHBmsnkUOLDGLfAqL7Utn2v6v-cCaRmnATjwq3LcvPg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting forcheckpoint  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting forcheckpoint  (Michael Banck <michael.banck@credativ.de>)
Список pgsql-hackers
On Mon, Feb 13, 2017 at 3:29 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
On 2/11/17 4:36 AM, Michael Banck wrote:
I guess you're right, I've moved it further down. There is in fact a
message about the xlog location (unless you switch off wal entirely),
but having another one right before that mentioning the completed
checkpoint sounds ok to me.

1) I don't think this should be verbose output. Having a program sit there "doing nothing" for no apparent reason is just horrible UI design.

That would include much of Unix then.. For example if I run "cp" on a large file it sits around "doing nothing". Same if I do "tar". No?

 
2) I think it'd be useful to have a way to get the status of a running checkpoint. The checkpointer already has that info, and I think it might even be in shared memory already. If there was a function that reported checkpoint status pg_basebackup could poll that to provide users with live status. That should be a separate patch though.

I agree that this would definitely be useful. But it might be something that's better exposed as a server-side view?

(and if pg_basebackup could poll it it would probably still not be included by default -- only if -P was given).

--

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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: [HACKERS] Commit fest 2017-01 will begin soon!
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: [HACKERS] removing tsearch2