Re: pgsql-server/src backend/storage/buffer/bufmgr ...
От | Bruce Momjian |
---|---|
Тема | Re: pgsql-server/src backend/storage/buffer/bufmgr ... |
Дата | |
Msg-id | 200401262044.i0QKicp05990@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql-server/src backend/storage/buffer/bufmgr ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-committers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> Not necessarily --- it could be out-of-disk-space, on at least some > >> filesystems. More to the point, the important thing is not to commit a > > > I assume the operating system is already allocating file system space > > during the write, and the sync is only forcing it to disk. > > Not so --- as was pointed out later in the thread, neither NFS nor AFS > work that way, and there could be other cases. > > In any case, I don't subscribe to the idea that we can just abdicate all > responsibility in case of hardware problems. Yes, we do rely on a disk > to keep storing information once it's accepted it, but that doesn't mean > that it's okay to ignore write-failure reports. We are failing to hold > up our end of the deal if we do that. Well, in normal usage, applications do the write and expect the data to be pushed to disk later, so I don't see us ignoring write() failures, but rather push to disk. Isn't a separate fsync after sync closer to reliable? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-committers по дате отправления: