Re: Relation extension scalability
От | Tom Lane |
---|---|
Тема | Re: Relation extension scalability |
Дата | |
Msg-id | 10634.1427677504@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Relation extension scalability (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > I thought the primary reason we did this is because we wanted to > write-and-fsync the block so that, if we're out of disk space, any > attendant failure will happen before we put data into the block. Once > we've initialized the block, a subsequent failure to write or fsync it > will be hard to recover from; basically, we won't be able to > checkpoint any more. If we discover the problem while the block is > still all-zeroes, the transaction that uncovers the problem errors > out, but the system as a whole is still OK. Yeah. As Andres says, the fsync is not an important part of that, but we do expect that ENOSPC will happen during the initial write() if it's going to happen. To some extent that's an obsolete assumption, I'm afraid --- I believe that some modern filesystems don't necessarily overwrite the previous version of a block, which would mean that they are capable of failing with ENOSPC even during a re-write of a previously-written block. However, the possibility of filesystem misfeasance of that sort doesn't excuse us from having a clear recovery strategy for failures during relation extension. regards, tom lane
В списке pgsql-hackers по дате отправления: