On Tue, Dec 7, 2010 at 1:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
