Arjen van der Meijden <[EMAIL PROTECTED]> writes:
> 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.
It's highly unlikely that that query has anything to do with it, since
it's not touching anything but system catalogs and not trying to write
them either.
> 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.
The first thing you ought to find out is which table
1663/2013826/9975789 is, and look to see if the corrupted LSN value is
already present on disk in that block. If it is, then we've probably
not got much chance of finding out how it got there. If it is *not* on
disk, but you have a repeatable way of causing this to happen starting
from a clean postmaster start, then that's pretty interesting --- but
I don't know any way of figuring it out short of groveling through the
code with a debugger. If you're not already pretty familiar with the PG
code, coaching you remotely isn't going to work very well :-(. I'd be
glad to look into it if you can get me access to the machine though.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
