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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
