Re: test_fsync label adjustments

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: test_fsync label adjustments
Дата
Msg-id 201101182241.p0IMfX703033@momjian.us
обсуждение исходный текст
Ответ на Re: test_fsync label adjustments  ("A.M." <agentm@themactionfaction.com>)
Ответы Re: test_fsync label adjustments  ("A.M." <agentm@themactionfaction.com>)
Список pgsql-hackers
A.M. wrote:
> >> Because the fastest option may not be syncing to disk. For example,
> >> the only option that makes sense on OS X is fsync_writethrough- it
> >> would be helpful if the tool pointed that out (on OS X only, obviously).
> > 
> > Yes, that would be a serious problem.  :-(
> > 
> > I am not sure how we would address this --- your point is a good one.
> 
> One general idea I had would be to offer some heuristics such as "this
> sync rate is comparable to that of one SATA drive" or "comparable to
> RAID 10 with X drives" or "this rate is likely too fast to be actually
> be syncing". But then you are stuck with making sure that the heuristics
> are kept up-to-date, which would be annoying.

That fails for RAID BBUs.

> Otherwise, the only option I see is to detect the kernel and compare
> against a list of known problematic methods. Perhaps it would be easier
> to compare against a whitelist. Also, the tool would likely need to
> parse "mount" output to account for problems with specific filesystems.
> 
> I am just throwing around some ideas...

That sounds pretty complicated.  One idea would be the creation of a
wiki where people could post their results, or ideally a tool that could
read the output and load it into a database for analysis with other
results.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Следующее
От: Tom Lane
Дата:
Сообщение: Re: test_fsync label adjustments