From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Creation of an empty table is not fsync'd at checkpoint |
Date: | 2022-01-27 22:39:22 |
Message-ID: | a19494fd-8449-b465-ed09-2e11fca5ad5b@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 28/01/2022 00:11, Thomas Munro wrote:
> On Fri, Jan 28, 2022 at 8:12 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>> On Fri, Jan 28, 2022 at 6:55 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>> I think the simplest fix is to call register_dirty_segment() from
>>> mdcreate(). As in the attached. Thoughts?
>>
>> +1
>
> [Testing]
>
> Erm, so now I see my new table in checkpoint's activities:
>
> openat(AT_FDCWD,"base/5/16399",O_RDWR,00) = 20 (0x14)
> fsync(20) = 0 (0x0)
>
> ... but we still never synchronize "base/5". According to our
> project's reading of the POSIX tea leaves we should be doing that to
> nail down the directory entry.
Really? 'base/5' is fsync'd by initdb, when it's created. I didn't think
we try to fsync() the directory, when a new file is created in it. We do
that with durable_rename() and durable_unlink(), but not with file creation.
Hmm, if a relation is dropped, we use plain unlink() to delete it (at
the next checkpoint). Should we use durable_unlink() there, or otherwise
arrange to fsync() the parent directory?
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2022-01-27 22:51:52 | Re: A test for replay of regression tests |
Previous Message | Andres Freund | 2022-01-27 22:36:32 | Re: A test for replay of regression tests |