From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pendingOps table is not cleared with fsync=off |
Date: | 2020-05-08 23:53:13 |
Message-ID: | CA+hUKGJxJWAABMpWzf4bpLvuTXdKKAEbkzK7PypUa1CbZV1Vog@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 9, 2020 at 9:21 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> I noticed that commit 3eb77eba5a changed the logic in
> ProcessSyncRequests() (formerly mdsync()) so that if you have fsync=off,
> the entries are not removed from the pendingOps hash table. I don't
> think that was intended.
Perhaps we got confused about what the comment "... so that changing
fsync on the fly behaves sensibly" means. Fsyncing everything you
missed when you turn it back on after a period running with it off
does sound a bit like behaviour that someone might want or expect,
though it probably isn't really enough to guarantee durability,
because requests queued here aren't the only fsyncs you missed while
you had it off, among other problems. Unfortunately, if you try that
on an assertion build, you get a failure anyway, so that probably
wasn't deliberate:
TRAP: FailedAssertion("(CycleCtr) (entry->cycle_ctr + 1) ==
sync_cycle_ctr", File: "sync.c", Line: 335)
> I propose the attached patch to move the test for enableFsync so that
> the entries are removed from pendingOps again. It looks larger than it
> really is because it re-indents the block of code that is now inside the
> "if (enableFsync)" condition.
Yeah, I found that git diff/show -w made it easier to understand that
change. LGTM, though I'd be tempted to use "goto skip" instead of
incurring that much indentation but up to you ...
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2020-05-09 00:10:58 | Re: [PATCH] Fix division by zero (explain.c) |
Previous Message | Alvaro Herrera | 2020-05-08 23:45:16 | Re: pg_restore error message |