If its really index corruption, then you should be able to fix it by
reindexing. However, that doesn't explain what caused the corruption.
Perhaps your hardware is bad in some way?
On Wed, Apr 24, 2013 at 10:46 PM, Adarsh Sharma eddy.ada...@gmail.com wrote:
Thanks Sergey for such a quick
On 2013-04-24 19:44:25 -0700, Sergey Konoplev wrote:
On Wed, Apr 24, 2013 at 5:05 PM, Adarsh Sharma eddy.ada...@gmail.com wrote:
I have a Postgresql 9.2 instance running on a CentOS6.3 box.Yesterday i
setup a hot standby by using pgbasebackup. Today i got the below alert from
standby box :
Sorry my bad , didn't mention the full DB version :
9.2.4.8 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.1.2
20080704 (Red Hat 4.1.2-52), 64-bit
Apart from these i am happy to inform , the issue is fixed now.
Actually there are two Slave set up's on the standby box on different
ports and
Hi all,
I have a Postgresql 9.2 instance running on a CentOS6.3 box.Yesterday i
setup a hot standby by using pgbasebackup. Today i got the below alert
from standby box :
[1] (from line 412,723)
2013-04-24 23:07:18 UTC [13445]: [6-1] user= db= host= PANIC:
_bt_restore_page: cannot add item to
On Wed, Apr 24, 2013 at 5:05 PM, Adarsh Sharma eddy.ada...@gmail.com wrote:
I have a Postgresql 9.2 instance running on a CentOS6.3 box.Yesterday i
setup a hot standby by using pgbasebackup. Today i got the below alert from
standby box :
[1] (from line 412,723)
2013-04-24 23:07:18 UTC
Thanks Sergey for such a quick response, but i dont think this is some
patch problem because we have other DB servers also running fine on same
version and message is also different :
host= PANIC: _bt_restore_page: cannot add item to page
And the whole day replication is working fine but at
