Re: Trap errors from streaming child in pg_basebackup to exit early

On Wed, Sep 29, 2021 at 4:48 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> > Other places in the code just refers to the background process as "the
> > background process". The term "WAL receiver" is new from this patch.
> > While I agree it's in many ways a better term, I think (1) we should
> > try to be consistent, and (2) maybe use a different term than "WAL
> > receiver" specifically because we have a backend component with that
> > name.
>
> Looking at the user-facing messaging we have before this patch, there is a bit
> of variability:
>
> On UNIX:
>
> pg_log_error("could not create pipe for background process: %m");
> pg_log_error("could not create background process: %m");
> pg_log_info("could not send command to background pipe: %m");
> pg_log_error("could not wait for child process: %m");
>
> On Windows:
>
> pg_log_error("could not create background thread: %m");
> pg_log_error("could not get child thread exit status: %m");
> pg_log_error("could not wait for child thread: %m");
> pg_log_error("child thread exited with error %u", ..);
>
> On Both:
>
> pg_log_info("starting background WAL receiver");
> pg_log_info("waiting for background process to finish streaming ...");
>
> So there is one mention of a background WAL receiver already in there, but it's
> pretty inconsistent as to what we call it. For now I've changed the messaging
> in this patch to say "background process", leaving making this all consistent
> for a follow-up patch.
>
> The attached fixes the above, as well as the typo mentioned off-list and is
> rebased on top of todays HEAD.

The documentation [1] of pg_basebackup specifies it as a "second
replication connection". Also, I see that the pg_receivewal.c using
the following message:
if (db_name)
{
pg_log_error("replication connection using slot \"%s\" is
unexpectedly database specific",
replication_slot);
exit(1);

We can use something like "stream replication connection" or
"background replication connection" or "background process/thread for
replication". Otherwise just "background process" on Unix and
"background thread" on Windows look fine to me. If others are okay, we
can remove the "WAL receiver" and use it consistently.

[1]
s
stream

Stream write-ahead log data while the backup is being taken. This
method will open a second connection to the server and start streaming
the write-ahead log in parallel while running the backup. Therefore,
it will require two replication connections not just one. As long as
the client can keep up with the write-ahead log data, using this
method requires no extra write-ahead logs to be saved on the source
server.

When tar format is used, the write-ahead log files will be written to
a separate file named pg_wal.tar (if the server is a version earlier
than 10, the file will be named pg_xlog.tar).

This value is the default.

Regards,
Bharath Rupireddy.