planned recovery from a certain transaction

Поиск
Список
Период
Сортировка
От Chris Spotts
Тема planned recovery from a certain transaction
Дата
Msg-id 00a801c9f5ab$48e500b0$daaf0210$@com
обсуждение исходный текст
Ответы Re: planned recovery from a certain transaction  (Richard Huxton <dev@archonet.com>)
Re: planned recovery from a certain transaction  (Alan Hodgson <ahodgson@simkin.ca>)
Re: planned recovery from a certain transaction  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: planned recovery from a certain transaction  (Scott Marlowe <scott.marlowe@gmail.com>)
Список pgsql-general

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 stuff, alters some DDL - you name it, it does it.  The rest of the day, the database is read only.  Autovacuum is not on, it was killing performance for it to kick on in the middle of the proc.  Vacuum is run right before the long procedure.  We typically wait until the guy onsite verifies the procedure went smoothly and then vacuum (Why? Because we’ve read enough of “well, you would have been able to restore that if the autovacuum wasn’t running”.  We have a backup so this is just a checking before vacuuming is technically unneeded.).  Don’t get me wrong, I’m a big autovacuum fan, just not for this specific case.

 

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 transaction, is there a better way to reset it right before that transaction happened?  Restoring the backup is a lengthy process because several of the tables that are affected are rather large.

 

Chris Spotts

 

 

 

 

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

Предыдущее
От: "Hartman, Matthew"
Дата:
Сообщение: Re: Vacuum on the database versus individual tables.
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: PG 8.3.7 initdb -E LATIN1 fails on Windows