From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Matthias Apitz <guru(at)unixarea(dot)de>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_basebackup |
Date: | 2023-11-20 10:01:57 |
Message-ID: | 0d65ed1b9fc5baabffb79029e8278e8562c95469.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 2023-11-20 at 07:30 +0100, Matthias Apitz wrote:
> We're facing in a customer installation (PostgreSQL 13.1 on Linux) the
> following problem for the first time and not reproducible:
13.1? Your immediate reaction should be "update to the latest minor release".
> ${BINDIR}/pg_basebackup -U ${DBSUSER} -Ft -z -D ${BACKUPDIR}-${DATE}-${NUM}
>
> The resulting stdout/stderr of the script:
>
> 16.11.2023-20:20:02: pg_basebackup the cluster to /Backup/postgres/sisis-20231116-1 ...
> pg_basebackup: could not receive data from WAL stream: server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> pg_basebackup: child process exited with error 1
>
> pg-error.log:
>
> 2023-11-16 20:34:13.538 CET [6250] LOG: terminating walsender process due to replication timeout
>
> Why the PostgreSQL server says something about "replication", we do
> pg_basebackup?
Because "pg_basebackup" uses a replication connection.
> Some more information:
>
> - wal_sender_timeout has default value (60s)
Increase "wal_sender_timeout", perhaps to 0 (which means "infinite").
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2023-11-20 10:07:23 | Re: Prepared statements versus stored procedures |
Previous Message | PGUser2020 | 2023-11-20 07:24:45 | Re: How can I return a UTF8 string from a hex representation in a latin9 database? |