K
K
Kuzma2012-03-16 09:32:08
PostgreSQL
Kuzma, 2012-03-16 09:32:08

How to rollback UPDATE in PostgreSQL via pg_xlog?

Yesterday a sadness happened to one of my databases - a request got into the "payments" table

update payments set amount = 0; where id in (2354,2353,1232)


Pay attention to the semicolon in the middle - all the data became equal to zero overnight.

By an unfortunate coincidence, there are no backups.

Googling on this topic, I found that there is a small chance to recover data from files located in the pg_xlog directory. Please note that I do not use PITR. Looking into this folder, I found a file there with a date of change equal to the date of the fakap, as much as 16 megabytes in size. Internally it is binary.

After that, I googled that these files can be viewed through xlogdump. He showed me something like this: Is it possible to return something from this? autovacuum was not enabled, there is a full copy of the PGDATA folder. Postgresql started, web server stopped. PostgreSQL 8.4

[cur:0/5770E87C, xid:355075, rmid:10(Heap), len:88/116, prev:0/5770E840] update: s/d/r:1663/90693/107093 block 1 off 36 to block 107 off 30
[cur:0/5770E8F0, xid:355075, rmid:11(Btree), len:34/62, prev:0/5770E87C] insert_leaf: s/d/r:1663/90693/107099 tid 20/101
[cur:0/5770E930, xid:355075, rmid:11(Btree), len:38/66, prev:0/5770E8F0] insert_leaf: s/d/r:1663/90693/107100 tid 42/146
[cur:0/5770E974, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770E930] insert_leaf: s/d/r:1663/90693/107101 tid 21/97
[cur:0/5770E9B0, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770E974] insert_leaf: s/d/r:1663/90693/107102 tid 28/7
[cur:0/5770E9EC, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770E9B0] insert_leaf: s/d/r:1663/90693/107103 tid 33/2
[cur:0/5770EA28, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770E9EC] insert_leaf: s/d/r:1663/90693/107104 tid 18/232
[cur:0/5770EA64, xid:355075, rmid:11(Btree), len:54/82, prev:0/5770EA28] insert_leaf: s/d/r:1663/90693/107105 tid 46/109
[cur:0/5770EAB8, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770EA64] insert_leaf: s/d/r:1663/90693/107106 tid 17/99
[cur:0/5770EAF4, xid:355075, rmid:10(Heap), len:84/112, prev:0/5770EAB8] update: s/d/r:1663/90693/107093 block 1 off 37 to block 107 off 31
[cur:0/5770EB64, xid:355075, rmid:11(Btree), len:34/62, prev:0/5770EAF4] insert_leaf: s/d/r:1663/90693/107099 tid 20/143
[cur:0/5770EBA4, xid:355075, rmid:11(Btree), len:34/62, prev:0/5770EB64] insert_leaf: s/d/r:1663/90693/107100 tid 30/80
[cur:0/5770EBE4, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770EBA4] insert_leaf: s/d/r:1663/90693/107101 tid 21/132
[cur:0/5770EC20, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770EBE4] insert_leaf: s/d/r:1663/90693/107102 tid 28/7
[cur:0/5770EC5C, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770EC20] insert_leaf: s/d/r:1663/90693/107103 tid 33/2
[cur:0/5770EC98, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770EC5C] insert_leaf: s/d/r:1663/90693/107104 tid 18/232
[cur:0/5770ECD4, xid:355075, rmid:11(Btree), len:50/78, prev:0/5770EC98] insert_leaf: s/d/r:1663/90693/107105 tid 40/100
[cur:0/5770ED24, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770ECD4] insert_leaf: s/d/r:1663/90693/107106 tid 30/137
[cur:0/5770ED60, xid:355075, rmid:10(Heap), len:84/112, prev:0/5770ED24] update: s/d/r:1663/90693/107093 block 1 off 38 to block 107 off 32
[cur:0/5770EDD0, xid:355075, rmid:11(Btree), len:34/62, prev:0/5770ED60] insert_leaf: s/d/r:1663/90693/107099 tid 20/187
[cur:0/5770EE10, xid:355075, rmid:11(Btree), len:34/62, prev:0/5770EDD0] insert_leaf: s/d/r:1663/90693/107100 tid 31/43
[cur:0/5770EE50, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770EE10] insert_leaf: s/d/r:1663/90693/107101 tid 21/152
[cur:0/5770EE8C, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770EE50] insert_leaf: s/d/r:1663/90693/107102 tid 28/7
[cur:0/5770EEC8, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770EE8C] insert_leaf: s/d/r:1663/90693/107103 tid 33/2
[cur:0/5770EF04, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770EEC8] insert_leaf: s/d/r:1663/90693/107104 tid 18/232
[cur:0/5770EF40, xid:355075, rmid:11(Btree), len:50/78, prev:0/5770EF04] insert_leaf: s/d/r:1663/90693/107105 tid 56/107
[cur:0/5770EF90, xid:355075, rmid:11(Btree), len:30/58, prev:0/5770EF40] insert_leaf: s/d/r:1663/90693/107106 tid 18/28


Answer the question

In order to leave comments, you need to log in

2 answer(s)
K
Kuzma, 2012-04-10
@Kuzma

Still managed to recover. I outlined the recovery process here: ikuznetsov.blogspot.com/2012/04/update-postgresql-pgxlog-pitr.html
Maybe it will come in handy for someone

A
alexius2, 2012-03-16
@alexius2

In WAL'ah information most likely is not needed. There is a small chance that it will be possible to extract data from the database files, more details here . It may be possible to restore this field using some indirect data from other tables or application logs.
PS I myself had a similar case, though I had a fresh backup. I had to restore from it + according to data from other tables. After that, he started a plate in which all changes in the balance are entered by the trigger.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question