From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | 两个孩子的爹 <1726002692(at)qq(dot)com> |
Cc: | pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15949: pg_basebackup failed(PG-12-Beta3) |
Date: | 2019-08-13 17:48:22 |
Message-ID: | CAMkU=1xVEbiRxynSawq=6xNgT582xVBWiOYEjASzY1WUc2cRuQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Mon, Aug 12, 2019 at 9:18 PM 两个孩子的爹 <1726002692(at)qq(dot)com> wrote:
> Hi :
> I only tested PG-12-Beta 3.
>
Could you try testing a released version (like 11.5), between the same two
machine? It could help rule some possibilities in or out.
Also, what are all your timeout settings? And your keep alive? And your
unix_socket_directories?
select name,setting from pg_settings where name like '%keep%' or name like
'%timeout%' or name like '%socket_direct%';
I suspect that something in your network (firewall, gateway, etc.) is
interfering with the connection. Turning on compression just slows down
the client (pg_basebackup) enough that it gives this interference time to
happen.
> Backup completed normally, but did not seem to end correctly.
>
In your first email, the server did think something went wrong:
"2019-08-12 18:20:03.417 CST [11446] LOG: could not receive data from
client: connect timeout"
I think the "connection timeout" part of this message is generated by your
OS, and PostgreSQL just passes it along. It doesn't seem to be a timeout
which PostgreSQL is expecting to happen, which makes me think the problem
is in your network rather than in PostgreSQL itself.
In the log in your most recent email, it does look like the server believes
everything completed normally, while only the client senses an error.
Again, it seems to me that something in your network is injecting itself
between the two ends of the connection.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2019-08-13 18:05:39 | BUG #15954: Unable to alter partitioned table to set logged |
Previous Message | naveen mahadevuni | 2019-08-13 17:35:39 | Re: BUG #15946: "duplicate key" error on ANALYZE of table partitions in transaction |