bricklen <bricklen@gmail.com> writes:
> On Wed, Dec 29, 2010 at 1:53 PM, bricklen <bricklen@gmail.com> wrote:
>> On Wed, Dec 29, 2010 at 12:11 PM, Tom Lane <tgl@sss.pgh.pa.us> 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
