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
