Re: Idea for getting rid of VACUUM FREEZE on cold pages - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Idea for getting rid of VACUUM FREEZE on cold pages
Date
Msg-id 4C08E5A80200002500031FA2@gw.wicourts.gov
Whole thread Raw
In response to Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Idea for getting rid of VACUUM FREEZE on cold pages
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> The best thought I've had so far is that if someone kept WAL
>> files long enough the evidence might be in there somewhere....
> 
> Hm, that is an excellent point.  The WAL trace would actually be a
> lot superior in terms of being able to figure out what went wrong.
> But I don't quite see how we tell people "either keep xmin or keep
> your old WAL".  Also, for production sites the amount of WAL you'd
> have to hang onto seems a bit daunting.
Any thoughts on how far back the WAL would need to go to deal with
the issues where such information has been useful?  (For example, we
always have at least two weeks worth, but I don't know if that's a
useful range or not.)
> Other problems are the cost of shipping it to a developer, and the
> impracticality of sanitizing private data in it before you show it
> to somebody.
Yeah, this wouldn't be a practical answer to the need unless
PostgreSQL shipped with a tool which could scan WAL and extract the
relevant information (probably under direction of someone from the
list or a private support organization).  Is the required
information predictable enough to make developing such a tool a
tractable problem?
-Kevin


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Working with PostgreSQL enums in C code
Next
From: Tom Lane
Date:
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages