On Wed, Nov 17, 2010 at 1:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> On 17.11.2010 17:11, Tom Lane wrote:
>>> The objection to that was not about performance. It was about how
>>> to find out what needs to be fsync'd.
>
>> I must be missing something: we handle that just fine with normal
>> tables, why is it a problem for unlogged tables?
>
> Hmm ... that's a good point. If we simply treat unlogged tables the
> same as regular for checkpointing purposes, don't we end up having
> flushed them all correctly during a shutdown checkpoint? I was thinking
> that WAL-logging had some influence on that logic, but it doesn't.
>
> Robert is probably going to object that he wanted to prevent any
> fsyncing for unlogged tables, but the discussion over in pgsql-general
> is crystal clear that people do NOT want to lose unlogged data over
> a clean shutdown and restart. If all it takes to do that is to refrain
> from lobotomizing the checkpoint logic for unlogged tables, I say we
> should refrain.
I think that's absolutely a bad idea. I seriously do not want to have
a conversation with someone about why their unlogged tables are
exacerbating their checkpoint I/O spikes. I'd be happy to have two
modes, though. We should probably revisit the syntax, though. One,
it seems that CREATE UNLOGGED TABLE is not as clear as I thought it
was. Two, when (not if) we add more durability levels, we don't want
to create keywords for all of them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
