Richard Neill <postgresql@xxxxxxxxxxxxxxxx> writes: >> This is unlikely to work unless you can also recover the pg_clog >> contents, which unfortunately might be pretty difficult to identify. > I can't find it. However, the failure was in the middle of the night, > and I think there's a pretty decent chance that postgres was idle at the > time - there was "probably" no transaction in progress, and the WAL > should have committed. That's all fine, but it only means that the right transactions would be marked committed in pg_clog. There's no very good reason to suppose that that marking has propagated back to the heap tuples in all cases. Actually though, I suspect a big chunk of your problem is that even tuples that are hinted committed will seem to be "in the future". You'd need to also recover pg_control, or at least reset it to something approximating the current XID counter, before stuff is likely to look sane. If you don't have pg_control, you might be able to dig around in the most recently modified tables and guess at the current XID by looking for the largest XIDs you can find. But, TBH, this is getting way past what you're likely to successfully pull off if you've never done it before. There are folks who do PG data recovery professionally [not me], and if your data is worth money to you, you'd be best off hiring someone who's done this before. If it's not, chalk this up to a learning experience, and set up a better backup system. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
