Re: AW: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: AW: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace
Дата
Msg-id 7793.984165630@sss.pgh.pa.us
обсуждение исходный текст
Ответ на AW: AW: AW: AW: WAL does not recover gracefully from ou t-of -dis k-sp ace  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
Список pgsql-hackers
Zeugswetter Andreas SB  <ZeugswetterA@wien.spardat.at> writes:
>> I attach my modified version of Andreas' program.  Note I do not
>> believe his assertion that close() implies fsync() --- on the
>> machines I've used, it demonstrably does not sync.

> Ok, I am not sure, but essentially do we need it to sync? The OS sure isn't
> supposed to notice after closing the file, that it ran out of disk space.

I believe that out-of-space would be reported during the writes, anyway,
so that's not the issue.

The point of fsync'ing after the prewrite is to ensure that the indirect
blocks are down on disk.  If you trust fdatasync (or O_DSYNC) to write
indirect blocks then it's not necessary --- but I'm pretty sure I heard
somewhere that some versions of fdatasync fail to guarantee that.

In any case, the real point of the prewrite is to move work out of the
transaction commit path, and so we're better off if we can sync the
indirect blocks during prewrite.

>> I tried this on HPUX 10.20, which has not only O_SYNC but also O_DSYNC

> AIX has O_DSYNC (which is _FDATASYNC) too, but I assumed O_SYNC 

Oh?  What speeds do you get if you use that?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Bixby
Дата:
Сообщение: porting question: funky uid names?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: porting question: funky uid names?