On 09.11.21 21:20, Tom Lane wrote:
Why is this different from the half-dozen
other fsync-error cases in the same file? Why, if fsync failure
here is so catastrophic, is it okay to just return a normal failure
code when tar_close doesn't even get to this point because of some
earlier error? At t
On Wed, Nov 17, 2021 at 02:19:20PM -0500, Tom Lane wrote:
> Pushed then; thanks for reviewing that. We can consider the fsync
> error question at leisure.
Fine by me. Thanks for the commit.
--
Michael
signature.asc
Description: PGP signature
Michael Paquier writes:
> On Tue, Nov 16, 2021 at 10:26:11PM -0500, Tom Lane wrote:
>> However, that's largely orthogonal to any of the things my proposed
>> patches are trying to fix. If you want to review the patches without
>> considering the fsync-error-handling problem, that'd be great.
> I
On Tue, Nov 16, 2021 at 10:26:11PM -0500, Tom Lane wrote:
> I feel like doing an immediate exit() for these errors and not other
> ones is a pretty terrible idea, mainly because it doesn't account for
> the question of what to do with a failure that prevents us from getting
> to the fsync() call in
Michael Paquier writes:
> Taking the issues with fsync() aside, which could be improved as a
> separate patch, is there anything I can do for this thread? The error
> handling problems in walmethods.c introduced by the integration of LZ4
> are on me, so I'd like to fix it. 0002 depends on some p
On Wed, Nov 10, 2021 at 02:03:11PM +0900, Michael Paquier wrote:
>> but this code seems about as fishy and ill-thought-out as anything
>> else I've touched here. Why is this different from the half-dozen
>> other fsync-error cases in the same file? Why, if fsync failure
>> here is so catastrophic
On Tue, Nov 09, 2021 at 03:20:31PM -0500, Tom Lane wrote:
> I think it's right. This certainly isn't sanctioned by the zlib
> specification [1], nor does it look like our other gzclose() calls,
> which simply consult errno. (Note that this coding is not at all new,
> but Coverity thinks it is bec
