Re: Creation of an empty table is not fsync'd at checkpoint

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Creation of an empty table is not fsync'd at checkpoint
Дата
Msg-id a19494fd-8449-b465-ed09-2e11fca5ad5b@iki.fi
обсуждение исходный текст
Ответ на Re: Creation of an empty table is not fsync'd at checkpoint  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Creation of an empty table is not fsync'd at checkpoint  (Andres Freund <andres@anarazel.de>)
Re: Creation of an empty table is not fsync'd at checkpoint  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
On 28/01/2022 00:11, Thomas Munro wrote:
> On Fri, Jan 28, 2022 at 8:12 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>> On Fri, Jan 28, 2022 at 6:55 AM Heikki Linnakangas <hlinnaka@iki.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: A test for replay of regression tests
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: A test for replay of regression tests