| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, marcin mank <marcin(dot)mank(at)gmail(dot)com>, Andy Colson <andy(at)squeakycode(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: unlogged tables |
| Date: | 2010-11-17 18:46:46 |
| Message-ID: | 16060.1290019606@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-11-17 18:48:56 | Re: unlogged tables |
| Previous Message | Tom Lane | 2010-11-17 18:41:19 | Re: Review: rollback sequence reset for TRUNCATE ... RESTART IDENTITY |