Thread: BUG #11882: make HAVE_WORKING_LINK an option
The following bug has been logged on the website: Bug reference: 11882 Logged by: david gauchard Email address: gauchard@laas.fr PostgreSQL version: 9.4beta2 Operating system: linux Description: Hi, 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): 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. Just a thought. david
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? > 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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
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
David Gauchard <gauchard@laas.fr> writes:
> On mer., nov. 05, 2014 at 05:35:14 +0100, Andres Freund wrote:
>> 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.
>> Those FS's really shouldn't be used for a database though. Are you
>> thinking of something concrete?
> 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).
Meh. There's a reason HAVE_WORKING_LINK is defined in pg_config_manual.h:
if you want to adjust it, you're supposed to do so manually.
I don't really want to carry a configure option to support
non-production-quality filesystems. Even just documenting it
would be painful (are we really going to have an option that
we'd tell people not to use?)
regards, tom lane