On 2016-03-05 07:43:00 +0900, Michael Paquier wrote: > On Sat, Mar 5, 2016 at 7:35 AM, Andres Freund <and...@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 <and...@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 ... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
