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@xxxxxxxxxxxxxxxx ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
