Re: [GENERAL] planned recovery from a certain transaction

2009-06-25 Thread Chris Spotts
> > Assuming that the data is mostly created from whole cloth each > morning, it might do to have two dbs, and rename one to replace the > other when you're ready. Gives you 20 or so hours to discover a screw > up and still have the backup db before you toss it away to build the > next day For t

Re: [GENERAL] planned recovery from a certain transaction

2009-06-25 Thread Greg Stark
>> The transaction itself works flawlessly, but every once and awhile the data >> the it uploads from comes in flawed and we have to find a way to reset it. If you can automate the tests for the flaws you can do the whole transaction itself as one big transaction in Postgres. Even DDL can be done

Re: [GENERAL] planned recovery from a certain transaction

2009-06-25 Thread Scott Marlowe
On Thu, Jun 25, 2009 at 9:40 AM, Chris Spotts wrote: > > > We have a database which has one long involved procedure early in the > morning that updates all sorts of things, moves data around, deletes some > stuff, alters some DDL - you name it, it does it.  The rest of the day, the > database is re

Re: [GENERAL] planned recovery from a certain transaction

2009-06-25 Thread Alvaro Herrera
Chris Spotts escribió: > The transaction itself works flawlessly, but every once and awhile the data > the it uploads from comes in flawed and we have to find a way to reset it. > This reset involves restoring a backup that was taken right before the proc > started. If we had the xid of the long

Re: [GENERAL] planned recovery from a certain transaction

2009-06-25 Thread Alan Hodgson
On Thursday 25 June 2009, "Chris Spotts" wrote: > The transaction itself works flawlessly, but every once and awhile the > data the it uploads from comes in flawed and we have to find a way to > reset it. This reset involves restoring a backup that was taken right > before the proc started. If w

Re: [GENERAL] planned recovery from a certain transaction

2009-06-25 Thread Richard Huxton
Chris Spotts wrote: The transaction itself works flawlessly, but every once and awhile the data the it uploads from comes in flawed and we have to find a way to reset it. This reset involves restoring a backup that was taken right before the proc started. If we had the xid of the long running

[GENERAL] planned recovery from a certain transaction

2009-06-25 Thread Chris Spotts
I know questions like this have been asked before, but I hadn't seen one quite from the same perspective (although I'm sure it's out there somewhere). We have a database which has one long involved procedure early in the morning that updates all sorts of things, moves data around, deletes some