Re: silent data loss with ext4 / all current versions
От | Andres Freund |
---|---|
Тема | Re: silent data loss with ext4 / all current versions |
Дата | |
Msg-id | 20160304224746.pwyyr2hsxzpckeqs@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: silent data loss with ext4 / all current versions (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: silent data loss with ext4 / all current versions
|
Список | pgsql-hackers |
On 2016-03-05 07:43:00 +0900, Michael Paquier wrote: > On Sat, Mar 5, 2016 at 7:35 AM, Andres Freund <andres@anarazel.de> wrote: > > On 2016-03-04 14:51:50 +0900, Michael Paquier wrote: > >> On Fri, Mar 4, 2016 at 4:06 AM, Andres Freund <andres@anarazel.de> wrote: > >> Hm. OK. I don't see any reason why switching to link() even in code > >> paths like KeepFileRestoredFromArchive() or pgarch_archiveDone() would > >> be a problem thinking about it. Should HAVE_WORKING_LINK be available > >> on a platform we can combine it with unlink. Is that in line with what > >> you think? > > > > I wasn't trying to suggest we should replace all rename codepaths with > > the link wrapper, just the ones that already have a HAVE_WORKING_LINK > > check. The name of the routine I suggested is bad though... > > So we'd introduce a first routine rename_or_link_safe(), say replace_safe(). Or actually maybe just link_safe(), which falls back to access() && rename() if !HAVE_WORKING_LINK. > > That's one approach, yes. Combined with the fact that you can't actually > > reliably rename across directories, the two could be on different > > filesystems after all, that'd be a suitable defense. It just needs to be > > properly documented in the function header, not at the bottom. > > OK. Got it. Or the two could be on the same filesystem. > Still, link() and rename() do not support doing their stuff on > different filesystems (EXDEV). That's my point ...
В списке pgsql-hackers по дате отправления: