Re: unlogged tables

On 17.11.2010 03:56, Robert Haas wrote:
> On Tue, Nov 16, 2010 at 7:46 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>>> On Tue, Nov 16, 2010 at 5:57 PM, marcin mank<marcin(dot)mank(at)gmail(dot)com> wrote:
>>>> Can (should ?) unlogged tables' contents survive graceful (non-crash) shutdown?
>>
>>> I don't think so. To make that work, you'd need to keep track of
>>> every backing file that might contain pages not fsync()'d to disk, and
>>> at shutdown time you'd need to fsync() them all before shutting down.
>>
>> This is presuming that we want to guarantee the same level of safety for
>> unlogged tables as for regular. Which, it seems to me, is exactly what
>> people *aren't* asking for. Why not just write the data and shut down?
>> If you're unlucky enough to have a system crash immediately after that,
>> well, you might have corrupt data in the unlogged tables ... but that
>> doesn't seem real probable.
>
> I have a hard time getting excited about a system that is designed to
> ensure that we probably don't have data corruption. The whole point
> of this feature is to relax the usual data integrity guarantees in a
> controlled way. A small but uncertain risk of corruption is not an
> improvement over a simple, predictable behavior.

I agree with Robert, the point of unlogged tables is that the system
knows to zap them away if there's any risk of having corruption in them.
A corrupt page can lead to all kinds of errors. We try to handle
corruption gracefully, but I wouldn't be surprised if you managed to
even get a segfault caused by a torn page if you're unlucky.

fsync()ing the file at shutdown doesn't seem too bad to me from
performance point of view, we tolerate that for all other tables. And
you can always truncate the table yourself before shutdown.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com