Try to take backups of that table & index only. If succeeded drop and recreate them. May be it fix your issue.
Thanks On Thu, May 16, 2013 at 11:14 PM, JotaComm <jota.c...@gmail.com> wrote: > Hello, Fabrízio > > > 2013/5/16 Fabrízio de Royes Mello <fabriziome...@gmail.com> > >> >> On Thu, May 16, 2013 at 11:12 AM, JotaComm <jota.c...@gmail.com> wrote: >> >>> >>> [...] >>> >>> Yesterday I identified the following messages in my log file (slave): >>> >>> user=,db= WARNING: page 6629 of relation base/20449/24818 is >>> uninitialized >>> user=,db= CONTEXT: xlog redo vacuum: rel 1663/20449/24818; blk 6631, >>> lastBlockVacuumed 6626 >>> user=,db= PANIC: WAL contains references to invalid pages >>> user=,db= CONTEXT: xlog redo vacuum: rel 1663/20449/24818; blk 6631, >>> lastBlockVacuumed 6626 >>> user=,db= LOG: startup process (PID 26293) was terminated by signal 6: >>> Aborted >>> user=,db= LOG: terminating any other active server processes >>> >>> Information: >>> >>> PostgreSQL 9.2.3 (master and slave) >>> Operational System: CentOS release 6.3 (Final) >>> The parameter full_page_writes is enabled in both servers. >>> >>> Analyzing the objects in my cluster (master) I identified the database >>> [20449] and the relation [24818]. The relation 24818 is an index, so I ran >>> the command REINDEX to try solving the problem. Immediately after, I tried >>> to up the slave but I received the same errors. >>> >>> user=,db= WARNING: page 6629 of relation base/20449/24818 is >>> uninitialized >>> user=,db= CONTEXT: xlog redo vacuum: rel 1663/20449/24818; blk 6631, >>> lastBlockVacuumed 6626 >>> user=,db= PANIC: WAL contains references to invalid pages >>> user=,db= CONTEXT: xlog redo vacuum: rel 1663/20449/24818; blk 6631, >>> lastBlockVacuumed 6626 >>> user=,db= LOG: startup process (PID 26293) was terminated by signal 6: >>> Aborted >>> user=,db= LOG: terminating any other active server processes >>> >>> As the problem is in the wal file, so the process (above) doesn't work >>> according my wish. >>> >>> Any idea? >>> >>> >> Hi JotaComm, >> >> IMHO as it is your slave you could just rebuild it. >> >> However if you want to make an attempt to recover you can do: >> >> 1) make a physical backup of this cluster >> 2) in your postgresql.conf set 'zero_damaged_pages = on' [1] >> 3) start your cluster >> >> I really don't know if it will work, but you can try... :-) >> > > Thanks for your suggestion :) > > I tried it and I had the same errors. I believe that will be necessary to > rebuild the cluster, because the problem is in the wal file. > > >> >> Regards, >> >> [1] >> http://www.postgresql.org/docs/9.2/static/runtime-config-developer.html#GUC-ZERO-DAMAGED-PAGES >> >> -- >> Fabrízio de Royes Mello >> Consultoria/Coaching PostgreSQL >> >> Blog sobre TI: http://fabriziomello.blogspot.com >> >> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello >> >> Twitter: http://twitter.com/fabriziomello >> > > > Regards > -- > JotaComm > http://jotacomm.wordpress.com >
