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

Re: WIP patch for tuple freezing issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Cc: pgsql-patches(at)postgreSQL(dot)org
Subject: Re: WIP patch for tuple freezing issues
Date: 2006-11-05 16:34:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> The patch seems to make VACUUM FULL FREEZE combination valid again, 
> which should be note in the docs.

Right, I haven't gotten around to fixing the VACUUM ref page yet but
this change is needed.  This is really fallout from Alvaro's previous
changes BTW: there is no longer any need for VACUUM FREEZE to try to
absolutely guarantee a fully-frozen table state.  All it is really doing
is guaranteeing there's nothing older than OldestXmin in there, and so
the fact that VACUUM FULL would put its own xid into the table isn't
a contradiction anymore.

BTW, I intend to say that FREEZE is deprecated in favor of the
equivalent of running VACUUM with vacuum_freeze_distance set to 0.
I'd like to remove it in 8.3 so as to get rid of one non-spec
reserved word.  Any objections?

> This comment in vacuum.c:

> /*
>   * If we froze any tuples, mark the buffer dirty, and write a WAL
>   * record recording the changes.  We must log the changes to be
>   * crash-safe if we truncate clog at conclusion of the vacuum.
>   */

> is not accurate.

OK, how about "... crash-safe against future truncation of clog."?

			regards, tom lane

In response to

pgsql-patches by date

Next:From: Simon RiggsDate: 2006-11-05 16:43:11
Subject: Re: [HACKERS] Bug in WAL backup documentation
Previous:From: Tom LaneDate: 2006-11-05 16:29:06
Subject: Re: Proposal: vacuum and autovacuum parameters to control freezing

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