Re: WAL and commit_delay

Matthew Kirkwood <matthew(at)hairy(dot)beasts(dot)org> writes:
> BTW, I have attached two patches which streamline log initialisation
> a little. The first (xlog-sendfile.diff) adds support for Linux's
> sendfile system call. FreeBSD and HP/UX have sendfile() too, but the
> prototype is different. If it's interesting, someone will have to
> come up with a configure test, as autoconf scares me.

I think we don't want to mess with something as unportable as that
at this late stage of the release cycle (quite aside from your later
note that it doesn't work ;-)).

> The second removes a further three syscalls from the log init path.
> There are a couple of things to note here:
> * I don't know why link/unlink is currently preferred over
> rename. POSIX offers strong guarantees on the semantics
> of the latter.
> * I have assumed that the close/rename/reopen stuff is only
> there for the benefit of Windows users, and ifdeffed it
> for everyone else.

The reason for avoiding rename() is that the POSIX guarantees are
the wrong ones: specifically, rename promises to overwrite an existing
destination, which is exactly what we *don't* want. In theory two
backends cannot be executing this code in parallel, but if they were,
we would not want to destroy a logfile that perhaps already contains
WAL entries by the time we finish preparing our own logfile. link()
will fail if the destination name exists, which is a lot safer.

I'm not sure about the close/reopen stuff; I agree it looks unnecessary.
But this function is going to be so I/O bound (particularly now that
it fills the file) that two more kernel calls are insignificant.

regards, tom lane