On 06/26/2014 09:44 AM, Karthik Iyer wrote:
> We reindexed all the primary and unique keys of all the tables, But we
> did not reindex the tables. You think we should do that also ?
Yes, you need to reindex. Part of the problem with this kind of table
corruption, is that PostgreSQL has applied data and index page
modifications to the binary files themselves. Due to this, there are
probably index rows pointing to incorrect or invalid data pages.
Reindexing the primary and unique indexes is a very good start, but any
queries that use regular indexes can still return invalid or mismatched
rows when compared to the primary/unique results. Those kind of
mismatches can result in unexpected behavior from applications.
> We managed to get the old server up. We are trying to play the
> difference in data by checking the log files(statement logs). You think
> there is any other easy alternatives ?
Probably not. Now that your slave has been promoted and had its own
write activity, the old primary is not useful as a source of binary
replay. You *can* use it to verify which rows are old/new while vetting
out corruption, though. It's a good source of data for checking the
consistency of the new primary.
--
Shaun Thomas
OptionsHouse, LLC | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas@optionshouse.com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
