On Tue, Aug 14, 2007 at 11:09:36PM +0800, Phoenix Kiula wrote:
> If I am reading this right, does this mean it is probably better to
> leave fsync as "fsync=off" on production machines?
No, you want "fsync=on" on any machine which holds data you
care about. And you want hardware which doesn't lie to you
so that "fsync is finished" really means the data is
on-disk. Else PostgreSQL cannot ensure ACID compliance.
> Specifying explicit BEGIN and COMMIT blocks should only commit when I
> want the DB to,
yes
> or will each UPDATE in the middle of this block get
> executed?
It will get executed but the effects will only become
publicly visible after COMMIT (assuming no errors in the
queries in which case you could issue COMMITs all day long
and still see no change in the database from the transaction
in which the error occurred)
> So, again, in the conf file, is this what you recommend:
>
> fsync=off
No.
> max_connections=100
Yes, depending on your usage patterns.
> The problem with simple CHECK constraints is that they can only
> reference the primary key in another table.
Not so. Or you need to explain what you mean by "simple
CHECK constraints".
> I am happy to do this, but I don't see an ALTER DATABASE command.
ALTER DATABASE is there, of course, but it doesn't help you.
> I would really like not to have to execute the CREATE DATABASE command
> again!
You'll have to, unfortunately, I fear. Once you go about it
take the opportunity and make sure the locale and encoding
settings of initdb are compatible with an UTF8 database.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346