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

Re: Freezing is not WAL-logged

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Freezing is not WAL-logged
Date: 2006-10-20 13:28:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> >Tom Lane wrote:
> >>"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> >>>I just noticed that freezing a tuple (in vacuumlazy.c) is not 
> >>>WAL-logged.
> >>The theory is that this doesn't matter because the tuple is committed
> >>either way ... it's equivalent to a hint-bit update which we don'ton
> >>WAL-log either.
> >
> >Also it'd be hugely expensive to log each freeze operation.  The
> >alternative would be to log a VACUUM FREEZE, but that has the potential
> >to cause enormous recovery runtime.
> Freezing isn't very common, and a single WAL record per page would be 
> enough. I can write the patch.

Yeah, you are right, I was thinking that we would freeze a lot of tuples
a lot of the time, but this is obviously not true.

> It does have the potential to increase recovery times, but I don't think 
> we can just cross our fingers and hope that no crash happens after 
> freezing some tuples.


My idea was to move relminxid to a new pg_class_nt non-transactional
catalog in 8.3, but we certainly need to give a solution for the problem
in 8.2.  I don't remember why I concluded that we were safe against this
problem, but you are right that we aren't.

Alvaro Herrera                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2006-10-20 13:53:08
Subject: Re: Freezing is not WAL-logged
Previous:From: Jason PalmerDate: 2006-10-20 12:38:02
Subject: BUG #2710: Intermittent hangs on sequence generation

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