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

Re: Race-condition with failed block-write?

From: Arjen van der Meijden <acm(at)tweakers(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Race-condition with failed block-write?
Date: 2005-09-13 06:37:55
Message-ID: 432673C3.2000505@tweakers.net (view raw or flat)
Thread:
Lists: pgsql-bugs
On 13-9-2005 0:26, Tom Lane wrote:
> Arjen van der Meijden <acm(at)tweakers(dot)net> 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

In response to

Responses

pgsql-bugs by date

Next:From: Angelo NeuschitzerDate: 2005-09-13 07:07:56
Subject: Re: Strange behavoir of batches
Previous:From: Puvi SubramanianDate: 2005-09-13 06:24:20
Subject: bug on starting postgres

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