Skip site navigation (1) Skip section navigation (2)

Re: Race-condition with failed block-write?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Arjen van der Meijden <acm(at)tweakers(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Race-condition with failed block-write?
Date: 2005-09-13 14:25:31
Message-ID: 22901.1126621531@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Arjen van der Meijden <acm(at)tweakers(dot)net> 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

In response to

Responses

pgsql-bugs by date

Next:From: Ed L.Date: 2005-09-13 16:29:34
Subject: Re: ia64-hp-hpux11.23 configure warnings
Previous:From: Abdulkadir NazifDate: 2005-09-13 14:14:54
Subject: BUG #1880: Installation failure

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group