Ужас. База на Psql 7.4.6. Нет резервной копии ... (вернее, есть, но трехнедельной давности:(). Местный админ серверов по этому поводу разводит руками - ну виноватого искать - последнее дело.

Писал запрос на обновление одной записи от имени postgres. Отвлекли, и не дописал where id = ... В результате обновил одним значением колонку во всей таблице (40000 записей). Попытка оборвать транзакцию не увенчалась успехом.
Чего делать ? Сервер пока остановлен, чтобы не было операций записи. Бухгалтерия в шоке, я тоже :(
Как я понимаю, пока не было vacuum в базе хранится предыдущее состояние таблицы. Или нет ? Если можно как-то его достать - помогите, pls ! Горю !

Вот что выдает утилита pg_controldata :

pg_control version number: 72
Catalog version number: 200310211
Database cluster state: shut down
pg_control last modified: Tue 29 Nov 2005 11:10:56 AM EET

Current log file ID: 1
Next log file segment: 35
Latest checkpoint location: 1/224FB76C
Prior checkpoint location: 1/224CDB34
Latest checkpoint's REDO location: 1/224FB76C
Latest checkpoint's UNDO location: 0/0
Latest checkpoint's StartUpID: 24
Latest checkpoint's NextXID: 2845407
Latest checkpoint's NextOID: 17315369
Time of latest checkpoint: Tue 29 Nov 2005 11:10:53 AM EET
Database block size: 8192
Blocks per segment of large relation: 131072
Maximum length of identifiers: 64
Maximum number of function arguments: 32
Date/time type storage: Floating point
Maximum length of locale name: 128
LC_COLLATE: ru_UA
LC_CTYPE: ru_UA

В каталоге /xlog есть файлы вчерашнего и сегодняшнего дня, в каталоге /clog есть файлы вчерашнего и сегодняшнего дня с соответствующим временем.

Как отменить транзакции по состоянию на вчера ?

Рапортую. Все оказалось очень хреново :(. Журналом транзакций воспользоваться нельзя, хотя в файлах xlog явно лежат исходные странички данных, которые модифицировались в той злощастной транзакции - смотришь, облизываешься, но ... По оценкам, мы потратили бы примерно неделю, чтобы написать свою утилиту разбора формата xlog-файлов, чтобы получить исходное состояние таблицы. Лихорадочные поиски готовых таких утилит ничего не дали.
Как я понял, система отката реализована только в версии psql 8.
Пришлось восстановить данные с архива трехнедельной давности и перенести оттуда нужный столбец, часть свежих данных в этот столбец получили из других таблиц путем несколькочасовых бдений до 12 ночи. А около 500 строк так и остались кривыми. Бухгалтера их еще долго будут разгребать. Ну, мы их пометили для их удобства :)
Возможно, что можно копать в сторону формата файла pg_control (он нигде явно не описан), в нем подменять значения checkpoint-ов и перезапускать postges в надежде, что будет восстановление с записанного насильно checkpoint-а. Но это только фантазия, скорее всего - не все так просто. Ну - мы еще исправили значение интервала между checkpoint-ами в сторону увеличения, чтоб хватило времени добежать и клацнуть питанием, в случае чего :-) Ну и приняли меры к резервному копированию.
В доке по WAL к версии 7.4 одни обещания, как все круто будет в 8-й версии. И вроде как оно там есть - никто не пробовал ?