Re: Help me recovering data

Поиск
Список
Период
Сортировка
От Stephan Szabo
Тема Re: Help me recovering data
Дата
Msg-id 20050216093431.M51532@megazone.bigpanda.com
обсуждение исходный текст
Ответ на Re: Help me recovering data  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Help me recovering data  (Bruno Wolff III <bruno@wolff.to>)
Re: Help me recovering data  (Richard Huxton <dev@archonet.com>)
Re: Help me recovering data  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, 16 Feb 2005, Tom Lane wrote:

> Stephan Szabo <sszabo@megazone.bigpanda.com> writes:
> > Right, but since the how to resolve it currently involves executing a
> > query, simply stopping dead won't allow you to resolve it. Also, if we
> > stop at the exact wraparound point, can we run into problems actually
> > trying to do the vacuum if that's still the resolution technique?
>
> We'd have to do something with a fair amount of slop.  The idea I was
> toying with just now involved a forcible shutdown once we get within
> say 100,000 transactions of a wrap failure; but apply this check only
> when in interactive operation.  This would allow the DBA to perform
> the needed VACUUMing manually in a standalone backend.
>
> The real question here is exactly how large a cluestick do you want to
> hit the DBA with.  I don't think we can "guarantee" no data loss with
> anything less than forced shutdown, but that's not so much a cluestick
> as a clue howitzer.
>
> Maybe
>
> (a) within 200,000 transactions of wrap, every transaction start
> delivers a WARNING message;
>
> (b) within 100,000 transactions, forced shutdown as above.

This seems reasonable, although perhaps the former could be something
configurable.  I'm not sure there's a good reason to allow the latter to
change unless there'd ever be a case where 100,000 transactions wasn't
enough to vacuum or something like that.

All in all, I figure that odds are very high that if someone isn't
vacuuming in the rest of the transaction id space, either the transaction
rate is high enough that 100,000 warning may not be enough or they aren't
going to pay attention anyway and the howitzer might not be bad.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Design notes for BufMgrLock rewrite
Следующее
От: "E.Rodichev"
Дата:
Сообщение: win32 performance - fsync question