mdclose() does not cope w/ FileClose() failure - Mailing list pgsql-hackers

From Noah Misch
Subject mdclose() does not cope w/ FileClose() failure
Date
Msg-id 20191222091930.GA1280238@rfd.leadboat.com
Whole thread Raw
Responses Re: mdclose() does not cope w/ FileClose() failure
Re: mdclose() does not cope w/ FileClose() failure
List pgsql-hackers
Forking thread "WAL logging problem in 9.4.3?" for this tangent:

On Mon, Dec 09, 2019 at 06:04:06PM +0900, Kyotaro Horiguchi wrote:
> I don't understand why mdclose checks for (v->mdfd_vfd >= 0) of open
> segment but anyway mdimmedsync is believing that that won't happen and
> I follow the assumption.  (I suspect that the if condition in mdclose
> should be an assertion..)

That check helps when data_sync_retry=on and FileClose() raised an error in a
previous mdclose() invocation.  However, the check is not sufficient to make
that case work; the attached test case (not for commit) gets an assertion
failure or SIGSEGV.

I am inclined to fix this by decrementing md_num_open_segs before modifying
md_seg_fds (second attachment).  An alternative would be to call
_fdvec_resize() after every FileClose(), like mdtruncate() does; however, the
repalloc() overhead could be noticeable.  (mdclose() is called much more
frequently than mdtruncate().)


Incidentally, _mdfd_openseg() has this:

    if (segno <= reln->md_num_open_segs[forknum])
        _fdvec_resize(reln, forknum, segno + 1);

That should be >=, not <=.  If the less-than case happened, this would delete
the record of a vfd for a higher-numbered segno.  There's no live bug, because
only segno == reln->md_num_open_segs[forknum] actually happens.  I am inclined
to make an assertion of that and remove the condition:

    Assert(segno == reln->md_num_open_segs[forknum]);
    _fdvec_resize(reln, forknum, segno + 1);

Attachment

pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: [PATCH] Increase the maximum value track_activity_query_size
Next
From: vignesh C
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions