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 по дате отправления: