Re: Idea for getting rid of VACUUM FREEZE on cold pages

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Idea for getting rid of VACUUM FREEZE on cold pages
Дата
Msg-id 4C08E5A80200002500031FA2@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Idea for getting rid of VACUUM FREEZE on cold pages  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Working with PostgreSQL enums in C code
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Idea for getting rid of VACUUM FREEZE on cold pages