Michael Paquier writes:
> On Wed, Dec 26, 2018 at 08:35:22PM -0500, Tom Lane wrote:
>> Oh, I see. Yeah, if we're ignoring errors anyway, the stat calls
>> seem redundant.
> For this one, I think that we could simplify as attached (this causes
> open() to fail additionally because of the sync fla
On Wed, Dec 26, 2018 at 08:35:22PM -0500, Tom Lane wrote:
> Oh, I see. Yeah, if we're ignoring errors anyway, the stat calls
> seem redundant.
For this one, I think that we could simplify as attached (this causes
open() to fail additionally because of the sync flags, but that's not
really worth w
Michael Paquier writes:
> On Wed, Dec 26, 2018 at 05:55:36PM -0500, Tom Lane wrote:
>> It appears to me that the code is intentionally not worrying about
>> fsync failure, so it seems wrong for it to FATAL out if it's unable
>> to open the file to fsync it. And it surely shouldn't do so if the
>>
On Wed, Dec 26, 2018 at 05:55:36PM -0500, Tom Lane wrote:
> It appears to me that the code is intentionally not worrying about
> fsync failure, so it seems wrong for it to FATAL out if it's unable
> to open the file to fsync it. And it surely shouldn't do so if the
> file isn't there.
My point is
Michael Paquier writes:
> On Wed, Dec 26, 2018 at 09:08:23PM +, Tom Lane wrote:
>> Fix failure to check for open() or fsync() failures.
>>
>> While it seems OK to not be concerned about fsync() failure for a
>> pre-existing signal file, it's not OK to not even check for open()
>> failure. Th
On Wed, Dec 26, 2018 at 09:08:23PM +, Tom Lane wrote:
> Fix failure to check for open() or fsync() failures.
>
> While it seems OK to not be concerned about fsync() failure for a
> pre-existing signal file, it's not OK to not even check for open()
> failure. This at least causes complaints fr
