17.06.2011, 21:24, "Merlin Moncure" <mmoncure(at)gmail(dot)com>:
> 2011/6/17 Антон Степаненко <zlobnynigga(at)yandex(dot)ru>;:
>> 17.06.2011, 20:19, "Merlin Moncure" <mmoncure(at)gmail(dot)com>;:
>>> On Fri, Jun 17, 2011 at 10:56 AM, Kevin Grittner
>>> <Kevin(dot)Grittner(at)wicourts(dot)gov>;; wrote:
>>>>> I still do not believe that this is hardware problem.
>>>> How would an application cause a bus error?
>>> unaligned memory access on risc maybe? what's this running on?
>> *****:~$ cat /proc/cpuinfo
>> processor : 0
>> processor : 23
>> vendor_id : GenuineIntel
>> cpu family : 6
>> model : 44
>> model name : Intel(R) Xeon(R) CPU E5645 @ 2.40GHz
> hm, I'm wondering if this
> has anything to do with your problem.
Thank you very much, very interesting link. I've compiled it under my ubuntu lucid - it really causes sigbus. But when compiled under CentOS 2.6.18 - it makes the same. So I am not sure that this is a bug.
And event if it is - why it occurs only when buffers are set to 12Gb and filled...
I've read some sources of postgresql, e.g. /src/backend/storage/smgr/md.c:
mdread(SMgrRelation reln, ForkNumber forknum, BlockNumber blocknum,
if (nbytes != BLCKSZ)
if (nbytes < 0)
errmsg("could not read block %u in file \"%s\": %m",
* Short read: we are at or past EOF, or we read a partial block at
* EOF. Normally this is an error; upper levels should never try to
* read a nonexistent block. However, if zero_damaged_pages is ON or
* we are InRecovery, we should instead return zeroes without
* complaining. This allows, for example, the case of trying to
* update a block that was later truncated away.
if (zero_damaged_pages || InRecovery)
MemSet(buffer, 0, BLCKSZ);
errmsg("could not read block %u in file \"%s\": read only %d of %d bytes",
This is the only place reporting errors like 'could not read block in file'.
Then I lookead at /src/backend/storage/file/fd.c:
FileRead(File file, char *buffer, int amount)
returnCode = read(VfdCache[file].fd, buffer, amount);
if (returnCode >= 0)
VfdCache[file].seekPos += returnCode;
* Windows may run out of kernel buffers and return "Insufficient
* system resources" error. Wait a bit and retry to solve it.
* It is rumored that EINTR is also possible on some Unix filesystems,
* in which case immediate retry is indicated.
/* OK to retry if interrupted */
if (errno == EINTR)
/* Trouble, so assume we don't know the file position anymore */
VfdCache[file].seekPos = FileUnknownPos;
First, comment started with 'It is rumored' looks suspiciosly =) But I am not a kernel developer, I am event not a C++ developer, so I trust authors.
I've read 'man read' and 'man 7 signal', and it is said that syscalls could be interrupted by some signals, including sigbus, but when they do so, they should return to normal behaviour.
"the call will be automatically restarted after the signal handler returns if the SA_RESTART flag was used; otherwise the call will fail with the error EINTR" - from man 7 signal
So as I far as I understand even if postgresql gets signal 7 it should experience EINTR and retry immediately. What I am trying to say is that I do not know why I am getting sigbus, but no matter where it comes from, according to sources postgresql should just try to read one more time, and one more, and so on until read succeeded. But I'm not quite sure what happens first - sigbus or 'could not read block' error.
In response to
pgsql-bugs by date
|Next:||From: Merlin Moncure||Date: 2011-06-17 20:33:57|
|Subject: Re: could not read block XXXXX in file "base/YYYYY/ZZZZZZ":
read only 160 of 8192 bytes|
|Previous:||From: Robert Haas||Date: 2011-06-17 18:48:05|
|Subject: Re: Behaviour of triggers on replicated and non replicated tables|