bricklen <bricklen@gmail.com> writes:
> On Wed, Dec 29, 2010 at 11:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> What can you tell us about what was happening on the source DB while
>> the backup was being taken?
> The source db has between 1000 and 3000 transactions/s, so is
> reasonably volatile. The two tables in question are not accessed very
> heavily though.
> Looking at the ctid and xmin between both databases, no, they don't
> seem to match exactly. Pardon my ignorance, but would those have
> changed due to vacuums, analyze, or any other forms of access?
The difference in ctid, and the values of xmin and relfrozenxid,
seems to confirm my suspicion that this wasn't just random cosmic rays.
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. I suspect the explanation
is that your technique for setting up the standby is flawed. You can't
just rsync and have a valid snapshot of the DB --- you need to be sure
that enough WAL gets replayed to fix any inconsistencies arising from
the time-extended nature of the rsync operation. But you didn't say
exactly how you did that.
regards, tom lane