On Thu, Sep 08, 2005 at 04:26:16PM +0100, Adam Witney wrote: > On 8/9/05 3:46 pm, "Tom Lane" <tgl@xxxxxxxxxxxxx> wrote: > > > Adam Witney <awitney@xxxxxxxxxx> 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)
