On Tue, Dec 7, 2010 at 1:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I'm also going to go through and change all instances of the word
>> "unlogged" to "volatile", per previous discussion. If this seems like
>> a bad idea to anyone, please object now rather than afterwards.
>
> Hm... I thought there had been discussion of a couple of different
> flavors of table volatility. Is it really a good idea to commandeer
> the word "volatile" for this particular one?
So far I've come up with the following possible behaviors we could
theoretically implement:
1. Any crash or shutdown truncates the table.
2. Any crash truncates the table, but a clean shutdown does not.
3. A crash truncates the table only if it's been written since the
last checkpoint; a clean shutdown does not truncate it.
The main argument for doing #1 rather than #2 is that we'd rather not
have to include unlogged table data in checkpoints. Andres Freund
made the argument that we could avoid that anyway, though, by just
doing an fsync() on every unlogged table file in the cluster at
shutdown time. If that's acceptable, then ISTM there's no benefit to
implementing #1 and we should just go with #2. If it's not
acceptable, then we have to think about whether and how to have both
of those behaviors.
#3 seems like a lot of work relative to #1 and #2 for a pretty
marginal increase in durability.
Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company