On Thu, Sep 08, 2005 at 04:26:16PM +0100, Adam Witney wrote:
> On 8/9/05 3:46 pm, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>
> > Adam Witney <awitney@sgul.ac.uk> writes:
> >> Here you go....
> >
> >> pg_filedump-3.0/pg_filedump -i -f -R 34318 34320 134401986.1
> >
> > Thanks. What it looks like to me is that block 34320 (really 165392)
> > is data from some other file altogether. It's evidently still Postgres
> > heap data, but instead of having 3 non-null columns as any toast row
> > ought to have, these rows have 77 columns many of which are nulls.
> > They've got OIDs, too. Possibly you can work out which table these
> > rows really belong to. It looks like this ought to be block 415664
> > of whatever table it belongs to (which would make it block 22448 of
> > the xxx.3 file of that table, if I did the math right).
>
> I only have one file with a .3 in that database...
How many columns does that table have?
> Or could it be from a different database altogether? (although none of
> the others get much updates at all)
It's not impossible ...
To Tom: could this be caused by a WAL recovery that wrote a page image
to the wrong table? I guess it is very unlikely because the CRC of the
WAL record would likely not match, but it's an idea.
--
Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com
"At least to kernel hackers, who really are human, despite occasional
rumors to the contrary" (LWN.net)
