Re: client-side fsync() error handling - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: client-side fsync() error handling
Date
Msg-id 20200212052819.GD1464@paquier.xyz
Whole thread Raw
In response to client-side fsync() error handling  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: client-side fsync() error handling
List pgsql-hackers
On Tue, Feb 11, 2020 at 09:22:54AM +0100, Peter Eisentraut wrote:
> Digging around through the call stack, I think changing fsync_fname() to
> just call exit(1) on errors instead of proceeding would address most of
> that.
>
> Thoughts?

Doing things as you do in your patch sounds fine to me for this part.
Now, don't we need to care about durable_rename() and make the
panic-like failure an optional choice?  From what I can see, this
routine is used now in the backend for pg_basebackup to rename
temporary history files or partial WAL segments.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pgsql: walreceiver uses a temporary replication slot by default
Next
From: Michael Paquier
Date:
Subject: Re: Getting rid of some more lseek() calls