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  (Michael Paquier <michael.paquier@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Fix checkpoint skip logic on idle systems by trackingLSN progress
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] pg_background contrib module proposal