Re: offline consistency check and info on attributes - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: offline consistency check and info on attributes
Date
Msg-id 4DB5B45A.5000406@fuzzy.cz
Whole thread Raw
In response to Re: offline consistency check and info on attributes  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: offline consistency check and info on attributes  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Dne 25.4.2011 18:16, Alvaro Herrera napsal(a):
> Excerpts from Tomas Vondra's message of dom abr 24 13:49:31 -0300 2011:
> 
>> Right now I do have a very simple tool that reads a given file and
>> performs a lot of checks at the block level (as described in bufpage.h),
>> and the next step should be validating basic structure of the tuples
>> (lengths). And that's the point where I'm stuck right now - I'm thinking
>> what might be the most elegant way to get info about attributes, without
>> access to the pg_attribute catalog (the tool is intended for offline
>> checks).
> 
> Each tuple declares its length.  You don't need to know each attribute's
> length to check that.  Doing attribute-level checks is probably
> pointless without catalog access.

Yes, I know the tuple length is in HeapTupleHeader (and I'm already
checking that), but that does not allow to check lengths of the
individual columns, especially those with varlena types.

That's a very annoying type of corruption, because the queries that do
not touch such columns seem to work fine, but once you attempt to access
the corrupted column you'll get something like this:

pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  invalid memory alloc
request size 4294967293

So the ability to check where a the column lengths do not make sense (in
this case it's a negative value) would be a nice thing. But without the
access to pg_attribute this seems to be very difficult.

Hmmm, maybe the idea to build it as an offline tool (to use it when the
DB is not running) is not a good idea ...

Tomas


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Foreign table permissions and cloning
Next
From: Tom Lane
Date:
Subject: Re: make check in contrib