Re: Running PostgreSQL as fast as possible no matter the consequences - Mailing list pgsql-performance

From Jeff Janes
Subject Re: Running PostgreSQL as fast as possible no matter the consequences
Date
Msg-id AANLkTinHOnp3LUFF7JB0nnpezSFp1M8kKN+i9PpaFwV+@mail.gmail.com
Whole thread Raw
In response to Re: Running PostgreSQL as fast as possible no matter the consequences  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Running PostgreSQL as fast as possible no matter the consequences
List pgsql-performance
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.

Cheers,

Jeff

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Postgres 9.0 has a bias against indexes
Next
From: Mladen Gogala
Date:
Subject: Re: Postgres 9.0 has a bias against indexes