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

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

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Writing Commit Status hint bits (was Re: [HACKERS] Constant
Date: 2005-07-20 06:27:43
Message-ID: 1121840863.16393.6.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Tue, 2005-07-19 at 22:24 -0400, Tom Lane wrote: 
> Simon Riggs <simon(at)2ndquadrant(dot)com> 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. If we were going to
move a table to WORM storage, then we'd have done VACUUM FREEZE first
anyway, which would be required to avoid XID wraparound. This patch
would then guarantee that no further system-initiated writes take place.

Not AFAICS.... comments from vacuum.c included:

/*
* Now scan all the pages that we moved tuples onto and update tuple
* status bits.  This is not really necessary, but will save time for
* future transactions examining these tuples.
*/
update_hint_bits(onerel, fraged_pages, num_fraged_pages,
last_move_dest_block, num_moved);

then again on the function itself...

/*
* update_hint_bits() -- update hint bits in destination pages
*
* Scan all the pages that we moved tuples onto and update tuple status
bits.
* This is normally not really necessary, but it will save time for
future
* transactions examining these tuples.
*

*
* For the non-freeze case, one wonders whether it wouldn't be better to
skip
* this work entirely, and let the tuple status updates happen someplace
* that's not holding an exclusive lock on the relation.
*/

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

AFAIK this has nothing to do with that, since those locks are not
persistent across a crash,,,but conceivably something in 2PC might be
effected. 

Best Regards, Simon Riggs


In response to

Responses

pgsql-hackers by date

Next:From: Jamie DeppelerDate: 2005-07-20 07:37:25
Subject: Problems compiling Postgresql 8.0.3 on 10.4
Previous:From: Tom LaneDate: 2005-07-20 02:24:34
Subject: Re: Writing Commit Status hint bits (was Re: [HACKERS] Constant WAL replay)

pgsql-patches by date

Next:From: Jamie DeppelerDate: 2005-07-20 07:37:25
Subject: Problems compiling Postgresql 8.0.3 on 10.4
Previous:From: Bruce MomjianDate: 2005-07-20 03:49:12
Subject: Fix for interval division/multiplication

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