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?  (Greg Smith <greg@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Vincenzo Romano
Дата:
Сообщение: Re: On Scalability
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Issues with Quorum Commit