From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: silent data loss with ext4 / all current versions |
Date: | 2016-02-04 09:02:32 |
Message-ID: | CAB7nPqRMfbFL6ysnbTi0a=p+etav7STYLVsoD+nWjYniHce5ow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 2, 2016 at 4:20 PM, Michael Paquier wrote:
> Not wrong, and this leads to the following:
> void rename_safe(const char *old, const char *new, bool isdir, int elevel);
> Controlling elevel is necessary per the multiple code paths that would
> use it. Some use ERROR, most of them FATAL, and a bit of WARNING. Does
> that look fine?
After really coding it, I finished with the following thing:
+int
+rename_safe(const char *old, const char *new)
There is no need to extend that for directories, well we could of
course but all the renames happen on files so I see no need to make
that more complicated. More refactoring of the other rename() calls
could be done as well by extending rename_safe() with a flag to fsync
the data within a critical section, particularly for the replication
slot code. I have let that out to not complicate more the patch.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
xlog-fsync-v4.patch | text/x-diff | 16.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-02-04 09:06:47 | Re: [patch] Proposal for \crosstabview in psql |
Previous Message | Etsuro Fujita | 2016-02-04 09:00:03 | Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs) |