Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> On Fri, Aug 20, 2004 at 01:36:39PM -0400, Tom Lane wrote:
>> I thought from the
>> beginning that the slru layer underneath pg_clog was bad from the point
>> of view of obfuscating the code, because it forced an awkward division
>> of labor between clog.c and slru.c. Now that I realize that there's not
>> that much behavior that we really want to share, I wonder whether we
>> shouldn't revert that change and make subtrans.c stand on its own.
> Maybe you are right. I think this is a bigger change and it's not badly
> needed, so it can wait to 8.1. Do you agree?
Not really. I think truncating pg_subtrans in a more aggressive fashion
is a "must do" for 8.0 because otherwise it will be a disk hog (it is 16
times bigger than pg_clog remember). And I'm unconvinced that we don't
have crash-safety issues right now, seeing that subtrans updates are not
WAL-logged but we are using pg_clog logic that is built around the
assumption that commits *are* WAL-logged. What I want to do at minimum
is install patches that ensure we won't look back further than
RecentGlobalXmin; truncate subtrans on that basis; and change the
subtrans code to forcibly zero the current active page of pg_subtrans
during postmaster start, rather than trusting what's on disk.
By the time we do that it might be easiest to just go ahead and make the
split. I am not fearful of reverting the clog code to a prior state as
far as testing goes --- we already know the pre-slru code worked.
I'll try to look at this over the weekend.
regards, tom lane