On Wed, Nov 17, 2010 at 1:46 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
