Re: fsync error handling in pg_receivewal, pg_recvlogical

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fsync error handling in pg_receivewal, pg_recvlogical
Date: 2019-06-25 12:23:05
Message-ID: 43bba31e-c520-2de0-1b02-5672bc7faf70@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-03-29 14:05, Michael Paquier wrote:
> Yes, I think that we are going to need an equivalent of that for all
> frontend tools. At various degrees, making sure that a fsync happens
> is also important for pg_dump, pg_basebackup, pg_rewind and
> pg_checksums so it is not only a problem of the two tools you mention.
> It seems to me that the most correct way to have those failures would
> be to use directly exit(EXIT_FAILURE) in file_utils.c where
> appropriate.

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.

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.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
0001-Handle-fsync-failures-in-pg_receivewal-and-pg_recvlo.patch text/plain 2.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-06-25 12:28:00 Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3
Previous Message Peter Eisentraut 2019-06-25 11:08:21 errbacktrace