From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: fallocate / posix_fallocate for new WAL file creation (etc...) |
Date: | 2013-06-01 02:31:02 |
Message-ID: | 20130601023102.GA252605@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 30, 2013 at 02:58:26PM +0200, Andres Freund wrote:
> > * Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> > > But really, I am not at all concerned about some obscure values being
> > > returned, but about a read() not being successful..
> After a bit of standard perusing writing a single byte to the end of the
> file after the fallocate ought to make at least the reading guaranteed
> to be defined. If we did seek(last_byte); write(); posix_fallocate() we
> should even always have defined content. Yuck.
This portion of the posix_fallocate() specification requires the hoped-for
effect on subsequent read() calls:
If the offset+ len is beyond the current file size, then posix_fallocate()
shall adjust the file size to offset+ len. Otherwise, the file size shall
not be changed.
-- http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html
When the file size increases, read()'s defined behavior switches from
returning short to retrieving zeros. There's no need for an additional
write() to ensure that.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-06-01 02:48:50 | Re: removing PD_ALL_VISIBLE |
Previous Message | Noah Misch | 2013-06-01 01:57:48 | Re: 9.3: Empty arrays returned by array_remove() |