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

Re: [HACKERS] WAL logging freezing

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] WAL logging freezing
Date: 2006-10-31 10:41:10
Message-ID: 45472846.7020504@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> The only alternative I can see is the one Heikki suggested: don't
> truncate clog until the freeze horizon.  That's safe (given the planned
> change to WAL-log tuple freezing) and clean and simple, but a permanent
> requirement of 250MB+ for pg_clog would put the final nail in the coffin
> of PG's usability in small-disk-footprint environments.  So I don't like
> it much.  I suppose it could be made more tolerable by reducing the
> freeze horizon, say to 100M instead of 1G transactions.  Anyone for a
> GUC parameter?  In a high-volume DB you'd want the larger setting to
> minimize the amount of tuple freezing work.  OTOH it seems like making
> this configurable creates a nasty risk for PITR situations: a slave
> that's configured with a smaller freeze window than the master is
> probably not safe.

If we go down that route, we really should make it a GUC parameter, and 
reduce the default at least for 8_1_STABLE.

I got another idea. If we make sure that vacuum removes any aborted xid 
older than OldestXmin from the table, we can safely assume that any xid 
< the current clog truncation point we are going to be interested in is 
committed. Vacuum already removes any tuple with an aborted xmin. If we 
also set any aborted xmax (and xvac) to InvalidXid, and WAL logged that, 
we would know that after vacuum commits, any xid < relvacuumxid in the 
vacuumed table was committed, regardless of the hint bits. We could then 
safely truncate the clog without flushing anything. This also seems safe 
for PITR.

The only performance hit would be the clearing of xmax values of aborted 
transactions, but that doesn't seem too bad to me because most 
transactions commit.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2006-10-31 14:24:12
Subject: Re: [HACKERS] WAL logging freezing
Previous:From: Richard HuxtonDate: 2006-10-31 09:17:44
Subject: View updating and nextval() workaround - will this ever break?

pgsql-patches by date

Next:From: Simon RiggsDate: 2006-10-31 14:24:12
Subject: Re: [HACKERS] WAL logging freezing
Previous:From: Thomas H.Date: 2006-10-31 06:23:37
Subject: Re: xlog lockup patch (was: BUG #2712: could not fsync segment: Permission)

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