Re: [HACKERS] Potential data loss of 2PC files
От | Jim Nasby |
---|---|
Тема | Re: [HACKERS] Potential data loss of 2PC files |
Дата | |
Msg-id | cf1b2bef-8676-5fd5-72de-be9e00f3ad32@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Potential data loss of 2PC files (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Potential data loss of 2PC files
|
Список | pgsql-hackers |
On 12/22/16 12:02 PM, Andres Freund wrote: > > On December 22, 2016 6:44:22 PM GMT+01:00, Robert Haas <robertmhaas@gmail.com> wrote: >> On Thu, Dec 22, 2016 at 12:39 PM, Andres Freund <andres@anarazel.de> >> wrote: >>> It makes more sense of you mentally separate between filename(s) and >> file contents. Having to do filesystem metatata transactions for an >> fsync intended to sync contents would be annoying... >> >> I thought that's why there's fdatasync. > Not quite IIRC: that doesn't deal with file size increase. All this would be easier if hardlinks wouldn't exist IIUC.It's basically a question whether dentry, inode or contents need to be synced. Yes, it sucks. IIRC this isn't the first time we've run into this problem... should pg_fsync() automatically fsync the directory as well? I guess we'd need a flag to disable that for performance critical areas where we know we don't need it (presumably just certain WAL fsyncs). -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532)
В списке pgsql-hackers по дате отправления: