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
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 |