Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting forcheckpoint

Поиск
Список
Период
Сортировка
От Michael Banck
Тема Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting forcheckpoint
Дата
Msg-id 1486978427.21010.6.camel@credativ.de
обсуждение исходный текст
Ответ на Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: [HACKERS] gitlab post-mortem: pg_basebackup waiting for checkpoint  (Magnus Hagander <magnus@hagander.net>)
Список pgsql-hackers
Hi,

Am Montag, den 13.02.2017, 09:31 +0100 schrieb Magnus Hagander:
> 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?

The expectation for all three commands is that, even if there is no
output on stdout, they will write data to the local machine. So you can
easily monitor the progress of cp and tar by running du or something in
a different terminal.

With pg_basebackup, nothing is happening on the local machine until the
checkpoint on the remote is finished; while this is obvious to somebody
familiar with how basebackups work internally, it appears to be not
clear at all to some users.

So I think notifying the user that something is happening remotely while
the local process waits would be useful, but on the other hand,
pg_basebackup does not print anything unless (i) --verbose is set or
(ii) there is an error, so I think having it mention the checkpoint in
--verbose mode only is acceptable.


Michael

-- 
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax:  +49 2166 9901-100
Email: michael.banck@credativ.de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer





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

Предыдущее
От: Rushabh Lathia
Дата:
Сообщение: Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw
Следующее
От: Erik Rijkers
Дата:
Сообщение: Re: [HACKERS] Logical replication existing data copy - sgml fixes