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

Re: [HACKERS] WAL logging freezing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] WAL logging freezing
Date: 2006-10-31 15:06:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> 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, 

The problem with that is all the extra WAL log volume it creates.  I'm
also concerned about the loss of forensic information --- xmax values
are frequently useful for inferring what's been going on in a database.
(This is another reason for not wanting a very short freeze interval BTW.)

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Richard HuxtonDate: 2006-10-31 16:01:01
Subject: Re: View updating and nextval() workaround - will this
Previous:From: Tom LaneDate: 2006-10-31 15:02:23
Subject: Re: View updating and nextval() workaround - will this ever break?

pgsql-patches by date

Next:From: Tom LaneDate: 2006-10-31 16:04:55
Subject: Re: [HACKERS] WAL logging freezing
Previous:From: Simon RiggsDate: 2006-10-31 14:24:12
Subject: Re: [HACKERS] WAL logging freezing

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