On Mon, Feb 24, 2020 at 05:03:07PM +0100, Peter Eisentraut wrote:
> committed
Thanks!
--
Michael
signature.asc
Description: PGP signature
On 2020-02-21 05:18, Michael Paquier wrote:
On Thu, Feb 20, 2020 at 10:10:11AM +0100, Peter Eisentraut wrote:
OK, added in new patch.
Thanks, that looks good.
committed
The frontends do neither right now, or at least the error handling is very
inconsistent and inscrutable. It would be pos
On Thu, Feb 20, 2020 at 10:10:11AM +0100, Peter Eisentraut wrote:
> OK, added in new patch.
Thanks, that looks good.
> The frontends do neither right now, or at least the error handling is very
> inconsistent and inscrutable. It would be possible in theory to add a retry
> option, but that would
On 2020-02-13 12:52, Michael Paquier wrote:
durable_rename() calls fsync_fname(), so it would be covered by this change.
The other file access calls in there can be handled by normal error
handling, I think. Is there any specific scenario you have in mind?
The old file flush is handled by your
On Thu, Feb 13, 2020 at 10:02:31AM +0100, Peter Eisentraut wrote:
> On 2020-02-12 06:28, Michael Paquier wrote:
>> 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_basebac
On 2020-02-12 06:28, Michael Paquier wrote:
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.
durable_re
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 th
Continuing the discussion from [0], there are still a number of fsync()
calls in client programs that are unchecked or where errors are treated
non-fatally.
Digging around through the call stack, I think changing fsync_fname() to
just call exit(1) on errors instead of proceeding would address
