Re: Help me recovering data - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: Help me recovering data
Date
Msg-id 4210E41E.5060106@familyhealth.com.au
Whole thread Raw
In response to Re: Help me recovering data  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Help me recovering data  (Doug McNaught <doug@mcnaught.org>)
Re: Help me recovering data  (pgsql@mohawksoft.com)
Re: Help me recovering data  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> I think you're pretty well screwed as far as getting it *all* back goes,
> but you could use pg_resetxlog to back up the NextXID counter enough to
> make your tables and databases reappear (and thereby lose the effects of
> however many recent transactions you back up over).
> 
> Once you've found a NextXID setting you like, I'd suggest an immediate
> pg_dumpall/initdb/reload to make sure you have a consistent set of data.
> Don't VACUUM, or indeed modify the DB at all, until you have gotten a
> satisfactory dump.
> 
> Then put in a cron job to do periodic vacuuming ;-)

This might seem like a stupid question, but since this is a massive data 
loss potential in PostgreSQL, what's so hard about having the 
checkpointer or something check the transaction counter when it runs and  either issue a db-wide vacuum if it's about
towrap, or simply 
 
disallow any new transactions?

I think people'd rather their db just stopped accepting new transactions 
rather than just losing data...

Chris


pgsql-hackers by date:

Previous
From: Ron Mayer
Date:
Subject: Re: Query optimizer 8.0.1 (and 8.0)
Next
From: pgsql@mohawksoft.com
Date:
Subject: Re: Help me recovering data