Skip site navigation (1) Skip section navigation (2)

Re: Writing Commit Status hint bits (was Re: [HACKERS] Constant WAL replay)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Writing Commit Status hint bits (was Re: [HACKERS] Constant WAL replay)
Date: 2005-07-20 17:20:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Wed, 2005-07-20 at 09:24 -0400, Tom Lane wrote:
>> We don't rely on any one write of them to work, but that doesn't mean
>> that we can indefinitely postpone writing them.

> OK, I think I understand where you're coming from now.

Apparently not :-(

> When VACUUM freezes the xid, it *does* make sense at that point to
> update the hint bits as a performance optimization.

The hint bits are not really relevant when xmin = FrozenTransactionId,
since any examiner of the tuple would consider that XID committed anyway.
Besides, the hint bit is guaranteed set in that scenario; note the
Assert where vacuum is setting it:

                    HeapTupleHeaderSetXmin(tuple.t_data, FrozenTransactionId);
                    /* infomask should be okay already */
                    Assert(tuple.t_data->t_infomask & HEAP_XMIN_COMMITTED);

The scenario in which the hint bit *must* be set is where it is for
an XID for which we have deleted the relevant section of pg_clog,
which we are willing to do well before freeze occurs, if we know that
all the relevant XIDs have been hinted.  See TruncateCLOG.  Your patch
breaks that logic by not considering hint-bit updates as changes that
must be flushed to disk by checkpoint.

> 1. Any block read may attempt to set hint bits, which dirties the block
> and must be written out. So *reads* can result in heavier write activity
> at checkpoint time.

Sure, but the alternative is heavier activity in repeated checks of
pg_clog to find out commit state that a previous examiner of the tuple
already found out.  The patch supposes that one write is worse than N
reads, which is clearly a loss at some not-exceedingly-large value of N.
If we thought that was a good tradeoff, we might as well not have the
hint bits at all.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2005-07-20 17:59:33
Subject: Re: Buildfarm issues on specific machines
Previous:From: Simon RiggsDate: 2005-07-20 16:26:43
Subject: Re: Writing Commit Status hint bits (was Re: [HACKERS] Constant

pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-07-20 17:21:45
Subject: Re: pgsql: Add 'day' field to INTERVAL so 1 day interval
Previous:From: Bruce MomjianDate: 2005-07-20 16:42:32
Subject: pgsql: Add 'day' field to INTERVAL so 1 day interval can be

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group