Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Dec 7, 2010 at 1:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> 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.
OK. I agree that #3 adds a lot of complexity for not much of anything.
If you've got data that's static enough that #3 adds a useful amount
of safety, then you might as well be keeping it in a regular table.
I think a more relevant question is how complicated it'll be to issue
those fsyncs --- do you have a concrete implementation in mind?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
