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

2005-07-20 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes:
 On Tue, 2005-07-19 at 22:24 -0400, Tom Lane wrote: 
 Simon Riggs [EMAIL PROTECTED] writes:
 Short patch enclosed to turn off writing of commit-status hint bits.
 
 Doesn't this entirely destroy the ability to truncate clog, and
 therefore the ability to survive XID wraparound?

 I hope not for all our sakes, since the hint bits are not WAL logged and
 anything that relies upon them would be fragile.

We don't rely on any one write of them to work, but that doesn't mean
that we can indefinitely postpone writing them.

regards, tom lane

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

   http://www.postgresql.org/docs/faq


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

2005-07-20 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] 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

---(end of broadcast)---
TIP 6: explain analyze is your friend


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

2005-07-19 Thread Tom Lane
Simon Riggs [EMAIL PROTECTED] writes:
 Short patch enclosed to turn off writing of commit-status hint bits.

Doesn't this entirely destroy the ability to truncate clog, and
therefore the ability to survive XID wraparound?

It probably also breaks subxact and multixact logging, but I haven't
looked closely...

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly