Re: WAL and O_DIRECT

Поиск
Список
Период
Сортировка
От Ravi Krishna
Тема Re: WAL and O_DIRECT
Дата
Msg-id 14d5342006a-2108-312c5@webstg-m03.mail.aol.com
обсуждение исходный текст
Ответ на Re: WAL and O_DIRECT  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-admin
Thanks Bruce and Tom. That pretty much explains it.


-----Original Message-----
From: Bruce Momjian <bruce@momjian.us>
To: Ravi Krishna <s.ravikrishna@aim.com>
Cc: tgl <tgl@sss.pgh.pa.us>; pgsql-admin <pgsql-admin@postgresql.org>
Sent: Thu, May 14, 2015 12:26 pm
Subject: Re: [ADMIN] WAL and O_DIRECT


On Thu, May 14, 2015 at 12:07:04PM -0400, Ravi Krishna wrote:> >> However ourDB2 folks are raising a concern that PG
WALwrites may not be crash safe, unlesswe are using> >> write back technology in SAN or SSD , which we are using.>> >
What'syour point exactly?  If the underlying hardware does not providedurable writes, there's> > nothing PG (or DB2)
cando to fix that.> > >Am I right in concluding that PG WAL writes without underlying h/w caching isnot crash proof.>
Fortunatelythese days caching is  ubiquitous in all SSD/SANtechnology. Both Oracle and DB2 always open WAL> logs in
O_DIRECT.Is thisthinking outdated with modern technology which caches writes. Wonder whyOracle/DB2> are not making
O_DIRECToptional. I am sure it will increase thewrite performance.Basically, O_DIRECT writes through the OS catch
directlytothe storage.Postgres writes to the OS cache, then uses fsync() or anotherOS call toflush that OS write to the
storage--- we just do it in twoparts.We turn off O_DIRECT for WAL writes because we know another processisgoing to read
itsoon, so in that case, we fall back the two-partsolutionof OS write and fsync-like OS call.--   Bruce Momjian
<bruce@momjian.us>http://momjian.us  EnterpriseDB                            http://enterprisedb.com  + Everyone has
theirown god. + 



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: WAL and O_DIRECT
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Missing timeline history file after execution of pg_upgrade