Re: Potential data loss of 2PC files

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Potential data loss of 2PC files
Date: 2016-12-27 11:31:42
Message-ID: 20161227113142.tug4v2bhq5lv7zen@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-12-27 12:16:22 Re: Support for pg_receivexlog --format=plain|tar
Previous Message Amit Langote 2016-12-27 10:07:50 Re: Declarative partitioning - another take