Movatterモバイル変換


[0]ホーム

URL:


Quick Links

mdclose() does not cope w/ FileClose() failure

From:Noah Misch <noah(at)leadboat(dot)com>
To:Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject:mdclose() does not cope w/ FileClose() failure
Date:2019-12-22 09:19:30
Message-ID:20191222091930.GA1280238@rfd.leadboat.com
Views:Whole Thread |Raw Message |Download mbox |Resend email
Thread:
Lists: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);

AttachmentContent-TypeSize
FileClose-test-v0.patchtext/plain3.7 KB
mdclose-FileClose-v1.patchtext/plain551 bytes

Responses

Browse pgsql-hackers by date

 FromDateSubject
Next Messagevignesh C2019-12-22 11:34:19Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous MessageJulien Rouhaud2019-12-22 08:06:41Re: [PATCH] Increase the maximum value track_activity_query_size

[8]ページ先頭

©2009-2026 Movatter.jp