On Thu, Nov 18, 2010 at 08:49:12AM +0100, Alban Hertroys wrote: > From the discussion so far it appears to me that > "unlogged" should probably be split into various gradations > of unlogged. There appear to be a number of popular > use-cases for such tables, with different requirements, That's precisely the point why this discussion doesn't lead to a *solution*. It can only lead to a *decision*. It seems that it needs to be decided first whether in the case of unWALed tables we want PostgreSQL to provide *means* or *policies*. The former are decidable and robustly implementable in a piece of infrastructure software like PostgreSQL. The latter are up to the whims of each deployment site. > Which leads me to think that people want three knobs to > play with: should the table be logged or not? Can it be > truncated at normal server restart or not? Should it be > included in dumps or not? And possibly, should it be fsynced > or not? Yep, your analysis breaks down the policy stage (the grading of "logged") into "modes" or "means" which people can apply to achieve a certain policies. That is why I argued for options: - alter database dump_unlogged_tables to on/off default on: better safe than sorry, point the gun but don't pull the trigger - pg_dump --include-unlogged-tables default: whatever alter database says - psqlrc: \set include_unlogged_tables to on/off default: doesn't exist, falls back to what "alter database" or --include-unlogged say That way I can use certain means to work out the policy I want, namely setting "alter database" to what it should be on this database waaay before the time comes when it is crucial to not forget --included-unlogged. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
