On Tue, Sep 03, 2019 at 10:58:18AM +0900, Michael Paquier wrote:
> Attached is an updated patch, which needs to go down to v10.
Committed, after doing more double-checks on it. Thanks for the
report, Takahashi-san.
--
Michael
signature.asc
Description: PGP signature
On Mon, Sep 02, 2019 at 05:38:56PM +0900, Michael Paquier wrote:
> Thinking wider, don't we have the same problem with wal_sender_timeout
> in the case where a sync request takes longer than the time it would
> take the backend to terminate the connection?
I have been able to work more on that, an
On Mon, Sep 02, 2019 at 08:06:22AM +, r.takahash...@fujitsu.com wrote:
> I'm not sure whether this patch should be applied to postgres below 11
> since I'm not sure whether the OS parameters (ex. tcp_retries2) cause the
> same error.
Thinking wider, don't we have the same problem with wal_sen
Hi Michael-san,
> Attached is a patch to do that, which should go down to v12 where
> tcp_user_timeout has been introduced. Takahashi-san, what do you
> think?
Thank you for creating the patch.
This patch is what I expected.
I'm not sure whether this patch should be applied to postgres below 1
On Mon, Sep 02, 2019 at 04:42:55AM +, r.takahash...@fujitsu.com wrote:
> I think fsync() for each tablespace is not necessary.
> Like pg_basebackup -F p, I think fsync() is necessary only once at the end.
Yes, I agree that we overlooked that part when introducing
tcp_user_timeout. It is possi
Hi
pg_basebackup -F t fails when fsync spends more time than tcp_user_timeout in
following environment.
[Environment]
Postgres 13dev (master branch)
Red Hat Enterprise Postgres 7.4
[Error]
$ pg_basebackup -F t --progress --verbose -h -D
pg_basebackup: initiating base backup, waiting for
