Re: Running PostgreSQL as fast as possible no matter the consequences

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Running PostgreSQL as fast as possible no matter the consequences
Дата
Msg-id 201101271707.p0RH7eM20612@momjian.us
обсуждение исходный текст
Ответ на Re: Running PostgreSQL as fast as possible no matter the consequences  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-performance
Jeff Janes wrote:
> On Tue, Jan 25, 2011 at 5:32 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > Robert Haas wrote:
> >> On Wed, Jan 19, 2011 at 12:07 PM, Bruce Momjian <bruce@momjian.us> wrote:
>
> >> > ? ? ? ?http://developer.postgresql.org/pgdocs/postgres/non-durability.html
> >>
> >> This sentence looks to me like it should be removed, or perhaps clarified:
> >>
> >> ? ? This does affect database crash transaction durability.
> >
> > Uh, doesn't it affect database crash transaction durability? ?I have
> > applied the attached patch to clarify things. ?Thanks.
>
> I think the point that was trying to be made there was that the other
> parameters only lose and corrupt data when the machine crashes.
> Synchronous commit turned off will lose data on a mere postgresql
> server crash, it doesn't require a machine-level crash to cause data
> loss.
>
> Indeed, the currently committed doc is quite misleading.
>
> " The following are configuration changes you can make
>     to improve performance in such cases;  they do not invalidate
>     commit guarantees related to database crashes, only abrupt operating
>     system stoppage, except as mentioned below"
>
> We've now removed the thing being mentioned below, but did not remove
> the promise we would be mentioning those things.

Excellent point.  The old wording was just too clever and even I forgot
why I was making that point.  I have updated the docs to clearly state
why this setting is different from the ones above.  Thanks for spotting
this.

Applied patch attached.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
index 0a10457..1bec5b1 100644
*** a/doc/src/sgml/perform.sgml
--- b/doc/src/sgml/perform.sgml
*************** SELECT * FROM x, y, a, b, c WHERE someth
*** 1157,1165 ****

       <listitem>
        <para>
!        Turn off <xref linkend="guc-synchronous-commit">;  there is no
         need to write the <acronym>WAL</acronym> to disk on every
!        commit.
        </para>
       </listitem>
      </itemizedlist>
--- 1157,1166 ----

       <listitem>
        <para>
!        Turn off <xref linkend="guc-synchronous-commit">;  there might be no
         need to write the <acronym>WAL</acronym> to disk on every
!        commit.  This does enable possible tranaction loss in case of
!        a <emphasis>database</> crash.
        </para>
       </listitem>
      </itemizedlist>

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

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: High load,
Следующее
От: Andy Colson
Дата:
Сообщение: Re: High load,