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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgsql-server/src backend/storage/buffer/bufmgr ...
Следующее
От: neilc@svr1.postgresql.org (Neil Conway)
Дата:
Сообщение: pgsql-server/doc/src/sgml libpq.sgml