>
> 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
>> 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
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
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
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
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
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