Simon Riggs wrote:
> On Mon, 2006-10-30 at 12:05 -0500, Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > Ugh.  Is there another solution to this?  Say, sync the buffer so that
> > > the hint bits are written to disk?
> > 
> > Yeah.  The original design for all this is explained by the notes for
> > TruncateCLOG:
> > 
> >  * When this is called, we know that the database logically contains no
> >  * reference to transaction IDs older than oldestXact.      However, we must
> >  * not truncate the CLOG until we have performed a checkpoint, to ensure
> >  * that no such references remain on disk either; else a crash just after
> >  * the truncation might leave us with a problem.
> > 
> > The pre-8.2 coding is actually perfectly safe within a single database,
> > because TruncateCLOG is only called at the end of a database-wide
> > vacuum, and so the checkpoint is guaranteed to have flushed valid hint
> > bits for all tuples to disk.  There is a risk in other databases though.
> > I think that in the 8.2 structure the equivalent notion must be that
> > VACUUM has to flush and fsync a table before it can advance the table's
> > relminxid.
> Ouch! We did discuss that also. Flushing the buffercache is nasty with
> very large caches, so this makes autovacuum much less friendly - and
> could take a seriously long time if you enforce the vacuum delay
> costings.
> ISTM we only need to flush iff the clog would be truncated when we
> update relminxid. Otherwise we are safe to update even if we crash,
> since the clog will not have been truncated. 

I don't understand.  When clog is actually going to be truncated, if
it's determined that there's any page that can be truncated, then a
checkpoint is forced.  If no page is going to be removed then there's no
checkpoint, which makes a lot of sense and of course avoids the problem
of useless flushes.

In fact I don't understand what's the point about multiple databases vs.
a single database.  Surely a checkpoint would flush all buffers in all
databases, no?  This would flush all hint bits, everywhere.  So this bug
does not really exist.

Alvaro Herrera                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to