bricklen <bricklen@xxxxxxxxx> writes: > On Wed, Dec 29, 2010 at 1:53 PM, bricklen <bricklen@xxxxxxxxx> wrote: >> On Wed, Dec 29, 2010 at 12:11 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >>> You did something on the source DB that rewrote the table with a new >>> relfilenode (possibly CLUSTER or some form of ALTER TABLE; plain VACUUM >>> or ANALYZE wouldn't do it). And for some reason the standby hasn't >>> picked up that change in the pg_class row. >> Definitely no CLUSTER commands were issued, and there should have been >> no ALTER commands issued (yesterday was a holiday, no one was here). >> Would a TRUNCATE have the same effect though? Yeah, that would assign a new relfilenode too. > Update: Set up the warm standby again and encountered the same issue, > with two of the three previously-identified tables -- the ones that > can get truncated throughout the day. We're going to try again > overnight when those tables are not truncated and see if that gives us > a correctly-working standby. I think you're missing the point here: there is something about your standby setup procedure that is causing you to get an inconsistent set of row states. Failing to access a table at all because of wrong relfilenode in pg_class is a really obvious symptom; but it's just a symptom it's not the core disease. Almost certainly, your user data is out of sync as well, ie there are probably partially-applied updates and so on. Avoiding a TRUNCATE isn't going to eliminate those other problems. There's another thread going on about an inconsistent standby, in which I think we identified the problem as being failure to copy over the backup_label file. That would cause the standby to not replay enough WAL, which would explain your problem nicely. I wonder whether you're doing that or something like it. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
