On 21/07/14 16:17, Tom Lane wrote:
db=# select page_header(get_raw_page(2836::oid::regclass::text, 'fsm',
1));
ERROR: block number 1 is out of range for relation pg_toast_1255
db=# select pg_relation_size(2836::oid::regclass, 'fsm');
pg_relation_size
--
=?ISO-8859-1?Q?Torsten_F=F6rtsch?= torsten.foert...@gmx.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.
On 22/07/14 16:58, Tom Lane wrote:
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));
=?ISO-8859-1?Q?Torsten_F=F6rtsch?= torsten.foert...@gmx.net writes:
On 22/07/14 16:58, Tom Lane wrote:
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
=?ISO-8859-1?Q?Torsten_F=F6rtsch?= torsten.foert...@gmx.net writes:
Another question, just out of curiosity, for vm and main forks I use
pg_relation_size to figure out the highest page number. That does not
work for fsm. I have at least one fsm file that it 24 kb. Fetching page
0 works, page 1
Hi,
we are using 9.3 with data checksums enabled. Now I am looking for a way
to check if all database blocks are still intact. First I tried
pg_filedump. In many cases it simply ignored tampered data blocks. It is
probably not made for this task.
Then I remembered about the pageinspect
On Sun, Jul 20, 2014 at 02:57:20PM +0200, Torsten Förtsch wrote:
I ran this query in a separate transaction. The memory was freed only
when the backend process exited.
Is there a way to work around this memory leak?
Why do you think it's a memory leak. You asked for the full dataset;
you
=?ISO-8859-1?Q?Torsten_F=F6rtsch?= torsten.foert...@gmx.net writes:
Then I remembered about the pageinspect extension. The following select
is a bit too verbose but it seems to do the job for everything except
fsm files.
SELECT c.oid::regclass::text as rel,
f.fork,
On 20/07/14 17:35, Tom Lane wrote:
=?ISO-8859-1?Q?Torsten_F=F6rtsch?= torsten.foert...@gmx.net writes:
Then I remembered about the pageinspect extension. The following select
is a bit too verbose but it seems to do the job for everything except
fsm files.
SELECT
On 20/07/14 16:02, Andrew Sullivan wrote:
Then I could also use it in production. But currently I
need it only to verify a backup.
If you need to verify a backup, why isn't pg_dump acceptable? Or is
it that you are somehow trying to prove that what you have on the
target (backup) machine
10 matches
Mail list logo
