| From: | Ninad Shah <nshah(dot)postgres(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Issue with pg_basebackup v.11 |
| Date: | 2021-10-23 03:33:51 |
| Message-ID: | CAOFEiBfP3nUsuua8-5UG24otLfr-F26YKzHNbrc_CG0dH6ywoQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hey Tom,
Thank you for your response. Actually, when we copy data using scp/rsync,
it works without any issue. But, it fails while attempting to transfer
using pg_basebackup.
Would keepalive setting address and mitigate the issue?
Regards,
Ninad Shah
On Fri, 22 Oct 2021 at 21:39, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Ninad Shah <nshah(dot)postgres(at)gmail(dot)com> writes:
> > What I observed is that it takes a couple of hours between below 2 lines.
>
> > 115454656/1304172127 kB (8%), 0/1 tablespace
> > (...atastaging/base/115868/154220.2)
> > pgbasebackup: could not read COPY data: could not receive data from
> server:
> > Connection timed out
>
> We have heard reports of network connections dropping while pg_basebackup
> is busy doing something disk-intensive such as fsync'ing. The apparent
> 2-hour delay here does not mean that pg_basebackup was out to lunch for
> 2 hours; more likely that reflects the TCP timeout delay before the kernel
> realizes that the connection is lost. The actual blame probably resides
> with some firewall or router that has a short timeout for idle
> connections.
>
> I'd try turning on fairly aggressive TCP keepalive settings for the
> connection, say keepalives_idle=30 or so.
>
> regards, tom lane
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2021-10-23 04:04:03 | Re: Python3 for PostgreSQL 14 |
| Previous Message | Дмитрий Иванов | 2021-10-23 02:58:19 | Python3 for PostgreSQL 14 |