From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Potential data loss of 2PC files |
Date: | 2016-12-22 21:33:52 |
Message-ID: | cf1b2bef-8676-5fd5-72de-be9e00f3ad32@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)com> wrote:
>> On Thu, Dec 22, 2016 at 12:39 PM, Andres Freund <andres(at)anarazel(dot)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)
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2016-12-22 21:41:15 | Re: pg_background contrib module proposal |
Previous Message | Andres Freund | 2016-12-22 19:34:07 | Re: Fix checkpoint skip logic on idle systems by tracking LSN progress |