On Wed, Jun 18, 2014 at 7:49 PM, Andres Freund <andres@2ndquadrant.com>
wrote:
> On 2014-06-18 09:45:46 -0400, Tom Lane wrote:
> > Andres Freund <andres@2ndquadrant.com> writes:
> > > On 2014-06-18 16:15:47 +0530, Pavan Deolasee wrote:
> > >> But I wonder if not flushing dirty buffers
> > >> of unlogged tables at a checkpoint is a bad idea anyways. User might
> expect
> > >> that the unlogged tables to sustain server crash or unclean shutdown
> if
> > >> there had been no writes after successful manual checkpoint(s).
> >
> > > They'll get reset at unlcean startup anyway. Independent of having been
> > > touched or not.
> >
> > I'm with Pavan on this one: it's *not* a good thing that manually issued
> > checkpoints skip unlogged tables. That's surprising, possibly dangerous,
> > and no case whatsoever has been made that anyone sees it as an important
> > performance benefit.
>
> I don't understand what dangers it has? Any unclean shutdown resets all
> unlogged tables.
>
>
Looks like there is no agreement on this. I agree with Andreas that given
the current mechanism of truncating unlogged relations at the end of redo
recovery, there is no danger in not flushing the dirty buffers belonging to
unlogged relation at a normal checkpoint. Having said that, I find it
confusing that we don't do that, for one reason that Tom explained and also
because there is practically just no way to flush those dirty buffers to
disk if the user wants so.
Also, there had been discussions about altering unlogged tables to normal
tables and we may also want to improve upon the current mechanism of
truncating unlogged relations at the end of recovery even if the table was
fully synced to the disk. It looks simpler to just flush everything instead
of devising a new flag for checkpoint.
Anyone else has an opinion on this?
Thanks,
Pavan
--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee
