Re: [HACKERS] Potential data loss of 2PC files - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Potential data loss of 2PC files
Date
Msg-id 20161227113142.tug4v2bhq5lv7zen@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Potential data loss of 2PC files  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Potential data loss of 2PC files
List pgsql-hackers
On 2016-12-27 14:09:05 +0900, Michael Paquier wrote:
> On Fri, Dec 23, 2016 at 3:02 AM, Andres Freund <andres@anarazel.de> wrote:
> > 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.
 
>
> I did more monitoring of the code... Looking at unlogged tables and
> empty() routines of access methods, isn't there a risk as well for
> unlogged tables? mdimmedsync() does not fsync() the parent directory
> either!

But the files aren't created there, so I don't generally see the
problem.  And the creation of the metapages etc. should be WAL logged
anyway.  So I don't think we should / need to do anything special
there.  You can argue however that we wouldn't necessarily fsync the
parent directory for the file creation, ever.  But that'd be more
smgrcreate's responsibility than anything.


> We could do that at checkpoint as well, actually, by looping through
> all the tablespaces and fsync the database directories.

That seems like a bad idea, as it'd force fsyncs on unlogged tables and
such.

Regards,

Andres



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] Declarative partitioning - another take
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Support for pg_receivexlog --format=plain|tar