Re: WAL and commit_delay

Matthew Kirkwood <matthew@hairy.beasts.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