"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> I don't agree: If the truncation points are at 1 million, 2 million etc,
> then if we advance the relvacuumxid from 1.2 million to 1.5 million,
> then crash, the hints bits for that last vacuum are lost. Sounds bad,
> but we have not truncated clog, so there is no danger.

You're still wrong though.  Suppose that VACUUM moves a particular rel's
relvacuumxid from 1.9 to 2.1 million, but because this rel is not
currently the oldest vacuumxid, it doesn't truncate clog.  Then we crash
and lose hint bits, but not the relvacuumxid change.  Then VACUUM
vacuums some other rel and advances its relvacuumxid from 1.9 to 2.1
million --- but this time that *was* the globally oldest value, and now
we think we can truncate clog at 2 million.  But the first rel might
still have some unhinted xids around 1.9 million.

> If you look at this another way, maybe you'll see what I'm saying: Only
> update relvacuumxid iff the update would allow us to truncate the clog.

Then you'll never update it at all, because there will always be some
other rel constraining the global min.

			regards, tom lane

In response to

• Re: [HACKERS] WAL logging freezing at 2006-10-31 00:01:00 from Simon Riggs

Responses

• Re: [HACKERS] WAL logging freezing at 2006-10-31 00:58:40 from Simon Riggs

pgsql-hackers by date

Next:	From: Tom Lane	Date: 2006-10-31 00:28:56
	Subject: Re: --single-transaction doc clarification
Previous:	From: Neil Conway	Date: 2006-10-31 00:18:04
	Subject: Re: --single-transaction doc clarification

pgsql-patches by date

Next:	From: Tom Lane	Date: 2006-10-31 00:28:56
	Subject: Re: --single-transaction doc clarification
Previous:	From: Neil Conway	Date: 2006-10-31 00:18:04
	Subject: Re: --single-transaction doc clarification