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+HiwqHNqRH3_vDGfw0QLLMf+t+LUvRMnS4toKZE1tr3dRqqrA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side  (Amit Langote <amitlangote09@gmail.com>)
Re: pg_stat_progress_basebackup - progress reporting forpg_basebackup, in the server side  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список pgsql-hackers
On Mon, Feb 3, 2020 at 11:04 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> So we now have the following ideas about the phase names for pg_basebackup.
>
> 1.
> initializing
>
> 2.
> 2-1. starting backup
> 2-2. starting file transfer
> 2-3. performing pg_start_backup
> 2-4. performing checkpoint
> 2-5. waiting for [ backup start ] checkpoint to finish
>
> 3.
> 3-1. streaming backup
> 3-2. transferring database files
> 3-3. streaming database files
> 3-4. transferring files
>
> 4.
> 4-1. stopping backup
> 4-2. finishing file transfer
> 4-3. performing pg_stop_backup
> 4-4. finishing backup
> 4-5. waiting for WAL archiving to finish
> 4-6. performing WAL archive
>
> 5.
> 1. transferring wal
> 2. transferring WAL files
>
> What conbination of these do you prefer?

I like:

1. initializing
2-5 waiting for backup start checkpoint to finish
3-3 streaming database files
4-5 waiting for wal archiving to finish
5-1 transferring wal (or streaming wal)

> > -  <varlistentry>
> > +  <varlistentry id="protocol-replication-base-backup" xreflabel="BASE_BACKUP">
> >
> > I don't see any new text in the documentation patch that uses above
> > xref, so no need to define it?
>
> The following description that I added uses this.
>
>      certain commands during command execution.  Currently, the only commands
>      which support progress reporting are <command>ANALYZE</command>,
>      <command>CLUSTER</command>,
> -   <command>CREATE INDEX</command>, and <command>VACUUM</command>.
> +   <command>CREATE INDEX</command>, <command>VACUUM</command>,
> +   and <xref linkend="protocol-replication-base-backup"/> (i.e., replication
> +   command that <xref linkend="app-pgbasebackup"/> issues to take
> +   a base backup).

Sorry, I missed that.  I was mistakenly expecting a different value of linkend.

Some comments on v3:

+     <entry>Process ID of a WAL sender process.</entry>

"a" sounds redundant.  Maybe:

of this WAL sender process or
of WAL sender process

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.

Thanks,
Amit



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

Предыдущее
От: Ian Barwick
Дата:
Сообщение: Re: Add %x to PROMPT1 and PROMPT2
Следующее
От: Takuma Hoshiai
Дата:
Сообщение: Re: Implementing Incremental View Maintenance