Yan: ERROR: could not read block 149

Evet, tabloda index yok, ayrıca snapshot alıp aynen dediğiniz gibi başka bir makinaya kurmak da işe yaramıyor çünkü cluster kopyalanırken hata veriyor. Yalnız bir dosyada da değil. Üzerinde çalıştığım veritabanında bir tablo hasarlı iken diğer veritabanlarında da farklı tablolarda benzer hasarlar var.
Üzerinde çalıştığım veritabanında pg_dump -T "hasarlıTabloAdı" şeklinde komut ile yedek almayı başardım ama diğer veri tabanlarında durum daha vahim. pg_dumpall çalışmasa da yalnızca global tabloları "pg_dumpall -g" ile (kullanıcı bilgi ve şifreleri vs) da alabildim. Sanırım bu noktadan sonra postgres sunucuyu kaldırıp temiz bir 8.4 kurmakdan başka yapılacak birşey kalmadı.
Ama son bir kurtarma denemesi için base içinden hasarlı tabloları silsem de "pg_xlog" dan da faydalanarak tabloları kurtarabilir miyim?

>________________________________
> Kimden: Erdinc Akkaya <hz(dot)root(at)gmail(dot)com>
>Kime: Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>
>Kopya: Uygar UZUNHASAN <uygaruzunhasan(at)yahoo(dot)com>; Postgres Listesi <pgsql-tr-genel(at)postgresql(dot)org>
>Gönderildiği Tarih: 12 Temmuz 2012 11:05 Perşembe
>Konu: Re: [pgsql-tr-genel] ERROR: could not read block 149
>
>
>index yok ki tabloda. ayrıyeten tabloda copy,select çalışmıyor nasıl taşıyacak?
>
>
>12 Temmuz 2012 10:49 tarihinde Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> yazdı:
>
>
>>Merhaba,
>>
>>
>>On Tue, 2012-07-10 at 08:40 -0700, Uygar UZUNHASAN wrote:
>>> INFO:  analyzing "public.hareket"ERROR:  could not read block 149 of
>>> relation 1663/517477/498735: No such file or directory
>>> ERROR:  could not read block 149 of relation 1663/517477/498735: No
>>> such file or directory
>>>
>>> Merhabalar
>>> Postgresql 8.3.7 sürüm (malesef Win server 2003) veritabanı sisteminde
>>> veya "hareket" tablosunda vacuum, analyze ve reindex gibi işlemleri
>>> yapmaya çalıştığımda, veya adı geçen tabloyu içeren bir sorgu
>>> çalıştırdığımda üstteki uyarıyı alıyorum.
>>
>>
>>http://www.postgresql.org/docs/9.1/static/release-8-3-18.html
>>
>>Fix btree index corruption from insertions concurrent with vacuuming
>>(Tom Lane)
>>
>>An index page split caused by an insertion could sometimes cause a
>>concurrently-running VACUUM to miss removing index entries that it
>>should remove. After the corresponding table rows are removed, the
>>dangling index entries would cause errors (such as "could not read block
>>N in file ...") or worse, silently wrong query results after unrelated
>>rows are re-inserted at the now-free table locations. This bug has been
>>present since release 8.2, but occurs so infrequently that it was not
>>diagnosed until now. If you have reason to suspect that it has happened
>>in your database, reindexing the affected index will fix things.
>>
>>Hata kesinlikle budur demiyorum, hatta 8.3.7'den o serideki son sürüm
>>olan 8.3.19'a kadar en az 6 tane veri bozulması ile ilgili hata
>>düzeltmesi var. 8.3.7 16 MArt 2009'da, yani 3 yıldan uzun bir süre önce
>>çıkmış. Keşke arada güncelleseydiniz, o zaman bu dertlerle karşılaşma
>>durumunuz olmazdı.
>>
>>Şimdi, eğer index corruption ise, o zaman indexi drop etmeyi
>>deneyebilirsiniz. Ben olsam şunları yapardım:
>>
>>* Aynı işletim sistemi (mimarisine kadar) ve 8.3'ün son PostgreSQL
>>sürümünü yeni bir makinaya kurardım.
>>* Mevcut verinin snapshot'ını alıp yeni makinaya aktarırdım
>>* Yeni PostgreSQL'i çalıştırıp, ilgili indexleri drop edip tekrar
>>yaratırdım.
>>* Sonra da kontrol ederdim.
>>
>>Umarım verinizi kurtarırsınız. Bundan sonra da düzenli yedek ve sürüm
>>güncelleme konusunda daha fazla dikkat edersiniz :-)
>>
>>İyi çalışmalar,
>>--
>>Devrim GÜNDÜZ
>>Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
>>PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
>>Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
>>http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz
>>
>
>
>