Re: O_DSYNC broken on MacOS X?
От | A.M. |
---|---|
Тема | Re: O_DSYNC broken on MacOS X? |
Дата | |
Msg-id | 5EBDB815-A31D-4178-A259-C69A77F60EB5@themactionfaction.com обсуждение исходный текст |
Ответ на | Re: O_DSYNC broken on MacOS X? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: O_DSYNC broken on MacOS X?
|
Список | pgsql-hackers |
On Oct 7, 2010, at 12:26 PM, Robert Haas wrote: > On Thu, Oct 7, 2010 at 11:45 AM, Greg Smith <greg@2ndquadrant.com> wrote: >> Robert Haas wrote: >>> Proposed doc patch attached. >> >> Looks accurate to me. I like the additional linking to the Reliability page >> you put in there too. Heavily referencing that important page from related >> areas is a good thing, particularly now that it's got a lot more details >> than it used to. > > Cool, thanks for the fast review. I suspect there are more details > that could stand to be added to the WAL reliability page as well, but > I don't know what they are so I can't add them. > > I still have the feeling that we have not put quite a large enough > red, blinking light around this issue, but I don't have a concrete > suggestion. I think the general problem is that there is no simple way to verify that a PostgreSQL commit is pushing the bits to persistentstorage. It would be helpful if there were a platform-specific, volume-specific tool to deduce this. Currently,there is no warning light that goes on when commits are not persistent. On Linux, a tool could check filesystem parameters, hdparm (if relevant), and hard drive and controller specs (possibly againsta blacklist of known liars). Perhaps a simpler tool could run a basic fsyncs-per-second test and prompt the DBA to check that the numbers are within therealm of possibility. How else can a DBA today ensure that a commit is a commit? Cheers, M
В списке pgsql-hackers по дате отправления: