On 2014-07-02 17:28:25 +0530, Pavan Deolasee wrote:
> On Fri, Jun 20, 2014 at 11:34 PM, Pavan Deolasee <pavan.deolasee@gmail.com>
> wrote:
> >
> >
> > 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?
> >
> >
> Since I did not hear anything on this, I created a patch that adds a new
> flag to tell checkpointer to flush all pages to the disk. Tom (and even I)
> have reservations about the approach, but I would nevertheless leave it to
> the committer to decide. IMV we must fix this bug one way or the other.
> Otherwise users face risk of failing to do clean shutdown.
I think one reason for the separate flag is that the checkpoint
performed by pg_start_backup/pg_basebackup shouldn't just become more
expensive because unlogged tables are needlessly flushed to disk. After
all, unlogged tables are used because normal tables have a too high
overhead in that scenario.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services