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)
Список
Дерево обсуждения
Creation of an empty table is not fsync'd at checkpoint Heikki Linnakangas <hlinnaka@iki.fi>
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>
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>
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 Thomas Munro <thomas.munro@gmail.com>
Re: Creation of an empty table is not fsync'd at checkpoint Heikki Linnakangas <hlinnaka@iki.fi>
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>
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 Daniel Gustafsson <daniel@yesql.se>
Re: Creation of an empty table is not fsync'd at checkpoint Heikki Linnakangas <hlinnaka@iki.fi>
On 28/01/2022 00:11, Thomas Munro wrote: > On Fri, Jan 28, 2022 at 8:12 AM Thomas Munro wrote: >> On Fri, Jan 28, 2022 at 6:55 AM Heikki Linnakangas 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 по дате отправления