Re: check database integrity

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Torsten Förtsch <torsten(dot)foertsch(at)gmx(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: check database integrity
Date: 2014-07-22 14:58:40
Message-ID: 22773.1406041120@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

=?ISO-8859-1?Q?Torsten_F=F6rtsch?= <torsten(dot)foertsch(at)gmx(dot)net> writes:
> On 21/07/14 16:17, Tom Lane wrote:
>> Could you trace through it and see where the results diverge? Also,
>> what's the actual size of the file on disk?

> After a fresh restart of the database I attached strace to the backend.
> There are only 2 lines in the output that mention that relation:
> open("base/25317/11790", O_RDWR) = 35
> lseek(35, 0, SEEK_END) = 8192
> This happened during this query:
> select get_raw_page(2836::oid::regclass::text, 'fsm', 1);
> Shouldn't it rather open 11790_fsm?

Doh. I looked right at this code in get_raw_page yesterday:

if (blkno >= RelationGetNumberOfBlocks(rel))
elog(ERROR, "block number %u is out of range for relation \"%s\"",
blkno, RelationGetRelationName(rel));

RelationGetNumberOfBlocks reports the length of the main fork ... but
this check is applied regardless of which fork we're reading. Should
be using RelationGetNumberOfBlocksInFork, of course.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Anil Menon 2014-07-22 16:46:23 Re: Referencing serial col's sequence for insert
Previous Message Adrian Klaver 2014-07-22 14:53:50 Re: Fwd: Need r_constraint_name