On 13-9-2005 0:26, Tom Lane wrote:
Arjen van der Meijden <[EMAIL PROTECTED]> writes:
There is still the question of how the LSN value got corrupted, but
we've probably missed any chance of finding that out now.
As a matter of fact, I just tested it again. Issuing that same query
will trigger the issue again when I execute it. I don't know whether the
query matters, but I know this one will trigger it, so I didn't try others.
This one has the issue as a result:
SELECT c.oid,
n.nspname,
c.relname
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE pg_catalog.pg_table_is_visible(c.oid)
AND c.relname ~ '^pwprijs$'
ORDER BY 2, 3;
After the above query nothing happens for a few seconds and then these
errors show up again:
[ - 2005-09-13 08:23:10 CEST @] ERROR: xlog flush request 29/67713428
is not satisfied --- flushed only to 29/2E73E53C
[ - 2005-09-13 08:23:10 CEST @] CONTEXT: writing block 21 of relation
1663/2013826/9975789
[ - 2005-09-13 08:23:10 CEST @] WARNING: could not write block 21 of
1663/2013826/9975789
I stopped postgresql again to prevent changes to the on-disk data. But I
did start postgresql a second time to see if that query would trigger it
again and it did.
So what can I do to help you find the issue?
Dumping the data to file and sending it to you would probably be a waste
of bandwidth and trouble. Apart from the fact that I'd have permission
of my employer to do so anyway.
Since its a development machine, access to it is a possibility. But if
you can give me a few pointers how to gather usefull information without
any "stranger" accessing the machine, that'd be nice.
Best regards,
Arjen van der Meijden
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
