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: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Heikki Linnakangas" <heikki(at)enterprisedb(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-11-01 14:50:56
Message-ID: 18776.1162392656@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> Do we need another GUC? I thought your observation about a PITR slave
> having that set lower than its master still remains unresolved.

No, AFAICS that's not an issue in this design.  The facts-on-the-ground
are whatever is recorded in pg_class.relvacuumxid, and whether a
particular table has been vacuumed with a shorter or longer freeze
window doesn't affect correctness.  In particular, a slave with
ambitions towards having a shorter window would still be unable to
truncate its clog before having re-vacuumed everything.  

So, not only could we have a GUC variable, but it could be USERSET;
there's no breakage risk as long as we constrain the value range to
something sane.

It strikes me that VACUUM FREEZE could be replaced by
	SET vacuum_freeze_limit = 0
	VACUUM ...
which would be a good thing because the FREEZE keyword has to be
partially reserved in this syntax, and that is contrary to spec.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2006-11-01 14:56:19
Subject: Re: [HACKERS] Index greater than 8k
Previous:From: Stephen FrostDate: 2006-11-01 14:33:22
Subject: Re: Design Considerations for New Authentication Methods

pgsql-patches by date

Next:From: Tom LaneDate: 2006-11-01 15:06:49
Subject: Re: Extended protocol logging
Previous:From: Dave CramerDate: 2006-11-01 12:02:53
Subject: Re: Extended protocol logging

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