pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
curious regression failures (was Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded)
5+ messages / 3 participants
[nested] [flat]

* curious regression failures (was Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded)
@ 2007-09-19 15:14  Tom Lane <tgl@sss.pgh.pa.us>
  0 siblings, 2 replies; 5+ messages in thread

From: Tom Lane @ 2007-09-19 15:14 UTC (permalink / raw)
  To: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>; +Cc: pgsql-hackers@postgreSQL.org, Andrew Dunstan <andrew@dunslane.net>

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> Tom Lane wrote:
>> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>>> ! ERROR:  could not read block 2 of relation 1663/16384/2606: read only 0 of 8192 bytes
>> 
>> Is that repeatable?  What sort of filesystem are you testing on?
>> (soft-mounted NFS by any chance?)

> doesn't seem to be repeatable :-(

Hmm ... 
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=luna_moth&dt=2007-09-19%2013:10:01

Exact same error --- is it at the same place in the tests where you saw it?

Now that I think about it, there have been similar transient failures
("read only 0 of 8192 bytes") in the buildfarm before.  It would be
helpful to collect a list of exactly which build reports contain
that string, but AFAIK there's no very easy way to do that; Andrew,
any suggestions?

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: curious regression failures (was Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded)
@ 2007-09-19 15:22  Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  1 sibling, 0 replies; 5+ messages in thread

From: Stefan Kaltenbrunner @ 2007-09-19 15:22 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@postgreSQL.org, Andrew Dunstan <andrew@dunslane.net>

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> Tom Lane wrote:
>>> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>>>> ! ERROR:  could not read block 2 of relation 1663/16384/2606: read only 0 of 8192 bytes
>>> Is that repeatable?  What sort of filesystem are you testing on?
>>> (soft-mounted NFS by any chance?)
> 
>> doesn't seem to be repeatable :-(
> 
> Hmm ... 
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=luna_moth&dt=2007-09-19%2013:10:01
> 
> Exact same error --- is it at the same place in the tests where you saw it?

looks like it is in a similiar place:

http://www.kaltenbrunner.cc/files/regression.diffs (I don't have more 
than this on that failure any more)


Stefan



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: curious regression failures (was Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded)
@ 2007-09-19 15:55  Andrew Dunstan <andrew@dunslane.net>
  parent: Tom Lane <tgl@sss.pgh.pa.us>
  1 sibling, 2 replies; 5+ messages in thread

From: Andrew Dunstan @ 2007-09-19 15:55 UTC (permalink / raw)
  To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>; pgsql-hackers



Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>   
>> Tom Lane wrote:
>>     
>>> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>>>       
>>>> ! ERROR:  could not read block 2 of relation 1663/16384/2606: read only 0 of 8192 bytes
>>>>         
>>> Is that repeatable?  What sort of filesystem are you testing on?
>>> (soft-mounted NFS by any chance?)
>>>       
>
>   
>> doesn't seem to be repeatable :-(
>>     
>
> Hmm ... 
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=luna_moth&dt=2007-09-19%2013:10:01
>
> Exact same error --- is it at the same place in the tests where you saw it?
>
> Now that I think about it, there have been similar transient failures
> ("read only 0 of 8192 bytes") in the buildfarm before.  It would be
> helpful to collect a list of exactly which build reports contain
> that string, but AFAIK there's no very easy way to do that; Andrew,
> any suggestions?
>
> 			
>   

pgbfprod=# select sysname, stage, snapshot from build_status where log ~ 
$$read only \d+ of \d+ bytes$$;
  sysname   |    stage     |      snapshot      
 -----------+--------------+---------------------
 zebra      | InstallCheck | 2007-09-11 10:25:03
 wildebeest | InstallCheck | 2007-09-11 22:00:11
 baiji      | InstallCheck | 2007-09-12 22:39:24
 luna_moth  | InstallCheck | 2007-09-19 13:10:01
(4 rows)


cheers

andrew




^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: curious regression failures (was Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded)
@ 2007-09-19 16:21  Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
  parent: Andrew Dunstan <andrew@dunslane.net>
  1 sibling, 0 replies; 5+ messages in thread

From: Stefan Kaltenbrunner @ 2007-09-19 16:21 UTC (permalink / raw)
  To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-hackers

Andrew Dunstan wrote:
> 
> 
> Tom Lane wrote:
>> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>>  
>>> Tom Lane wrote:
>>>    
>>>> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>>>>      
>>>>> ! ERROR:  could not read block 2 of relation 1663/16384/2606: read
>>>>> only 0 of 8192 bytes
>>>>>         
>>>> Is that repeatable?  What sort of filesystem are you testing on?
>>>> (soft-mounted NFS by any chance?)
>>>>       
>>
>>  
>>> doesn't seem to be repeatable :-(
>>>     
>>
>> Hmm ...
>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=luna_moth&dt=2007-09-19%2013:10:01
>>
>>
>> Exact same error --- is it at the same place in the tests where you
>> saw it?
>>
>> Now that I think about it, there have been similar transient failures
>> ("read only 0 of 8192 bytes") in the buildfarm before.  It would be
>> helpful to collect a list of exactly which build reports contain
>> that string, but AFAIK there's no very easy way to do that; Andrew,
>> any suggestions?
>>
>>            
>>   
> 
> pgbfprod=# select sysname, stage, snapshot from build_status where log ~
> $$read only \d+ of \d+ bytes$$;
>  sysname   |    stage     |      snapshot     
> -----------+--------------+---------------------
> zebra      | InstallCheck | 2007-09-11 10:25:03
> wildebeest | InstallCheck | 2007-09-11 22:00:11
> baiji      | InstallCheck | 2007-09-12 22:39:24
> luna_moth  | InstallCheck | 2007-09-19 13:10:01

hmm all of those seem to fail the foreign key checks in a very similiar
way and that are vastly different platforms (windows,solaris,openbsd and
linux).


Stefan



^ permalink  raw  reply  [nested|flat] 5+ messages in thread

* Re: curious regression failures (was Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded)
@ 2007-09-19 16:34  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Andrew Dunstan <andrew@dunslane.net>
  1 sibling, 0 replies; 5+ messages in thread

From: Tom Lane @ 2007-09-19 16:34 UTC (permalink / raw)
  To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>; pgsql-hackers

Andrew Dunstan <andrew@dunslane.net> writes:
> pgbfprod=# select sysname, stage, snapshot from build_status where log ~ 
> $$read only \d+ of \d+ bytes$$;
>   sysname   |    stage     |      snapshot      
>  -----------+--------------+---------------------
>  zebra      | InstallCheck | 2007-09-11 10:25:03
>  wildebeest | InstallCheck | 2007-09-11 22:00:11
>  baiji      | InstallCheck | 2007-09-12 22:39:24
>  luna_moth  | InstallCheck | 2007-09-19 13:10:01
> (4 rows)

Fascinating.  So I would venture that (1) it's definitely our bug,
not something we could blame on NFS or whatever, and (2) we introduced
it fairly recently.  That specific error message wording exists only
in HEAD, but it's been there since 2007-01-03, so if there were a
pre-existing problem you'd think there would be some more matches.

The patterns I notice here are (1) they're all InstallCheck not Check
failures; (2) though not all at the same place in the tests, it's
a fairly short range; (3) it's all references to system catalogs,
though not all the same one.

My gut feeling is that we're seeing autovacuum truncate off an empty end
block and then a backend tries to reference that block again.  But there
should be enough interlocks in place to prevent such references.  Any
ideas out there?

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 5+ messages in thread


end of thread, other threads:[~2007-09-19 16:34 UTC | newest]

Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-09-19 15:14 curious regression failures (was Re: [PATCHES] PL/TCL Patch to prevent postgres from becoming multithreaded) Tom Lane <tgl@sss.pgh.pa.us>
2007-09-19 15:22 ` Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
2007-09-19 15:55 ` Andrew Dunstan <andrew@dunslane.net>
2007-09-19 16:21   ` Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
2007-09-19 16:34   ` Tom Lane <tgl@sss.pgh.pa.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox