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...)  (Jon Nelson <jnelson+pgsql@jamponi.net>)
Список 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 по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: 9.3: Empty arrays returned by array_remove()
Следующее
От: Robert Haas
Дата:
Сообщение: Re: removing PD_ALL_VISIBLE