From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fsync error handling in pg_receivewal, pg_recvlogical |
Date: | 2019-06-26 04:11:31 |
Message-ID: | 20190626041131.GI1714@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 25, 2019 at 02:23:05PM +0200, Peter Eisentraut wrote:
> Yeah, there is more to do. The reason I'm focusing on these two right
> now is that they would typically run as a background service, and a
> clean exit is most important there. In the other cases, the program
> runs more often in the foreground and you can see error messages. There
> are also some cases where fsync() failures are intentionally ignored
> ((void) casts), so some of that would need to be investigated further.
The remaining three calls all go through file_utils.c.
> Here is a patch to get started. Note that these calls don't go through
> file_utils.c, so it's a separate issue anyway.
Why using a different error code. Using EXIT_FAILURE is a more common
practice in the in-core binaries. The patch looks fine to me except
that, that's a good first cut.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | nagaura.ryohei@fujitsu.com | 2019-06-26 04:13:36 | [patch]socket_timeout in interfaces/libpq |
Previous Message | Tom Lane | 2019-06-26 03:52:28 | mcvstats serialization code is still shy of a load |