Re: Creation of an empty table is not fsync'd at checkpoint
От | Thomas Munro |
---|---|
Тема | Re: Creation of an empty table is not fsync'd at checkpoint |
Дата | |
Msg-id | CA+hUKG+tte+JUQHx9pFatRSXofG_qWE8upU=kWBeidt0pThsXQ@mail.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
|
Список | pgsql-hackers |
On Fri, Jan 28, 2022 at 7:28 AM Andres Freund <andres@anarazel.de> wrote: > On 2022-01-27 19:55:45 +0200, Heikki Linnakangas wrote: > > I was not able to reproduce this without the tablespace on a different > > virtual disk, I presume because ext4 orders the writes so that the > > checkpoint implicitly always flushes the creation of the file to disk. > > It's likely that the control file sync at the end of a checkpoint has the side > effect of also forcing the file creation to be durable if on the same > tablespace (it'd not make the file contents durable, but they don't exist > here, so ...). It might be possible to avoid that on xfs or pretty much any other file system. I wasn't following this closely, but even with ext4's recent fast commit changes, its fsync implementation still deliberately synchronises data for other file descriptors as a side effect as summarised in [1], unlike xfs and other systems. So they've caught up with xfs's concurrent writes (and gone further than xfs by doing it also for buffered I/O giving up even page-level atomicity, as discussed in a couple of other threads), but not yet decided to pull the trigger on just-fsync-what-I-asked-for. [1] https://lwn.net/Articles/842385/
В списке pgsql-hackers по дате отправления: