Re: fallocate / posix_fallocate for new WAL file creation (etc...)
От | Noah Misch |
---|---|
Тема | Re: fallocate / posix_fallocate for new WAL file creation (etc...) |
Дата | |
Msg-id | 20130601023102.GA252605@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: fallocate / posix_fallocate for new WAL file creation (etc...) (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: fallocate / posix_fallocate for new WAL file creation (etc...)
|
Список | pgsql-hackers |
On Thu, May 30, 2013 at 02:58:26PM +0200, Andres Freund wrote: > > * Andres Freund (andres@2ndquadrant.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
В списке pgsql-hackers по дате отправления: