Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side
Дата
Msg-id CA+HiwqFv0MwXeRS0zRq8G+q_9wmfN_mLcvTHxWM2N3V+y_9SUw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side  (Amit Langote <amitlangote09@gmail.com>)
Список pgsql-hackers
On Tue, Feb 4, 2020 at 10:34 AM Amit Langote <amitlangote09@gmail.com> wrote:
> Reading this:
>
> +     <entry><structfield>backup_total</structfield></entry>
> +     <entry><type>bigint</type></entry>
> +     <entry>
> +      Total amount of data that will be streamed. If progress reporting
> +      is not enabled in <application>pg_basebackup</application>
> +      (i.e., <literal>--progress</literal> option is not specified),
> +      this is <literal>0</literal>.
>
> I wonder how hard would it be to change basebackup.c to always set
> backup_total, irrespective of whether --progress is specified with
> pg_basebackup or not?  It seems quite misleading to leave it set to 0,
> because one may panic that they have lost their data, that is, if they
> haven't first read the documentation.

For example, the attached patch changes basebackup.c to always set
tablespaceinfo.size, irrespective of whether --progress was passed
with BASE_BACKUP command.  It passes make check-world, so maybe safe.
Maybe it would be a good idea to add a couple of more comments around
tablespaceinfo struct definition, such as how 'size' is to be
interpreted.

Thanks,
Amit

Вложения

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

Предыдущее
От: "imai.yoshikazu@fujitsu.com"
Дата:
Сообщение: RE: Complete data erasure
Следующее
От: Michael Paquier
Дата:
Сообщение: Refactor compile-time assertion checks for C/C++