Re: inconsistent state after crash recovery
| От | Robert Haas |
|---|---|
| Тема | Re: inconsistent state after crash recovery |
| Дата | |
| Msg-id | CA+TgmoYapNH2nDE15yMkRt61X4by+5bfGRgetyt-gDbQW-uXmQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: inconsistent state after crash recovery (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: inconsistent state after crash recovery
|
| Список | pgsql-hackers |
On Fri, Jul 26, 2013 at 8:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andres Freund <andres@2ndquadrant.com> writes: >> On 2013-07-26 13:33:13 +0900, Satoshi Nagayasu wrote: >>> Is this expected or acceptable? > >> I'd say it's both. > > Postgres is built on the assumption that the underlying filesystem is > reliable, ie, once you've successfully fsync'd some data that data won't > disappear. If the filesystem fails to honor that contract, it's a > filesystem bug not a Postgres bug. Nor is it reasonable to expect > Postgres to be able to detect every such violation. As an example, > would you expect crash recovery to notice the disappearance of a file > that was touched nowhere in the replayed actions? Eh, maybe not. But should we try harder to detect the unexpected disappearance of one that is? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: