Re: about some parameters

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: about some parameters
Date: 2010-01-01 17:21:02
Message-ID: 2040.1262366462@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> writes:
> Every time i explain what is the fsync parameter for, the next thing i
> always say is: "never turn it off", and now that we have
> synchronous_commit there is no good reason for turn fsync off... so
> why are we still let it be in the postgresql.conf where it's so
> vulnerable to a misguided dba?

It's a "never turn it off *in production*" kind of setting. That
doesn't make it useless --- in development or debug situations it
might be just fine.

The larger picture here is that just making sure fsync is on doesn't
mean squat as far as the safety of your data goes :-(. You also need
to be sure that every hardware/software layer below Postgres is honoring
fsync; which is a much harder thing to be sure of. In fact, one of the
most reliable end-to-end tests I can think of for that is to see whether
turning off fsync creates a major speed change. So we would not really
accomplish much by removing or hiding the parameter, and we would take
away a simple but important test procedure.

> another parameter that is interesting is seq_page_cost, AFAIUI all the
> other cost parameters (in the planner section of course) are relative
> to this one. so what is the logic in allow changing it?

Please read the discussions that went on when we added that parameter.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-01-01 17:24:50 Re: Cancelling idle in transaction state
Previous Message Simon Riggs 2010-01-01 16:30:05 Re: Cancelling idle in transaction state