From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql(at)mohawksoft(dot)com, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Kouber Saparev <postgresql(at)saparev(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Help me recovering data |
Date: | 2005-02-16 17:18:42 |
Message-ID: | 25316.1108574322@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2005-02-16 17:20:03 | Re: Help me recovering data |
Previous Message | pgsql | 2005-02-16 17:16:38 | Re: Help me recovering data |