On mer., nov. 05, 2014 at 05:35:14 +0100, Andres Freund wrote:
> Hi,
>
> On 2014-11-05 14:44:48 +0000, gauchard@laas.fr wrote:
> > This define "HAVE_WORKING_LINK" should not be always enabled. On systems
> > that support (and surely use) hard links FS, postgresql might be used on a
> > subFS not supporting it.
> > In the sources, the comment is (from git's
> > src/backend/access/transam/xlog.c):
>
> Those FS's really shouldn't be used for a database though. Are you
> thinking of something concrete?
Something surely not serious enough for you:
I was working on a fuse filesystem which I test using the
phoronix test suite, which uses postgresql for benchmarking, when
I ran into this bug (hard link is not always implementable).
I understand that this is not consistent enough for making a patch.
However at least a ./configure option (not in the manual config
file) would be welcome for automating processes. This would
not harm regular postgresql performances (because of no runtime
check for an option) and would be explicit.
>
> > 3373 * Prefer link() to rename() here just to be really sure that we
> > don't
> > 3374 * overwrite an existing logfile. However, there shouldn't be one,
> > so
> > 3375 * rename() is an acceptable substitute except for the truly
> > paranoid.
>
> > My thinking is that you may add a '--paranoid' option to use hardlink
> > instead of rename, or, at least, an option (--relax ?) to disable this
> > behaviour and use a regular rename() instead.
>
> I don't think this is really warranted by anything.
I agree.
Is a ./configure option acceptable ?
I can provide a patch for that if it be welcome.
Otherwise you tell me and I stay around my playground :)
david