Chris Travers wrote:
> lec wrote:
>
>> Scott Marlowe wrote:
>>
>>> On Sun, 2004-08-08 at 19:43, lec wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> I'm observing the following:
>>>> If I commit the following records 1,2,3,4,5,6,7,8,9,10 to the
>>>> database and the server hangs, I could lose records 5,6,7,8,9 but
>>>> record 10 is there. How is this possible and do anyone know how
>>>> Postgresql physically writes the records?
>>>>
>>>
>>>
>>> Assuming a properly function storage subsystem and a kernel that does
>>> not lie about fsync, this is not possible.
>>>
>>> Are you running on top of IDE drives with the write cache enabled?
>>> Most, if not all, IDE drives lie about FSYNC and can lose data if power
>>> is disconnected abrubtly.
>>>
>>>
>> SCSI
>>
>>> Or if you are running with fsync=false in postgresql.conf the same
>>> thing
>>> can happen. Otherwise, not, it should not happen. More info perhaps?
>>>
>>>
>>>
>>>
>> I didn't change the default fsync, which I believe is fsync=true.
>
>
> Could your SCSI controller be misbehaving? Could this be leading to a
> system hang (say when swap space is being called back into memory)?
The first hardware that got replaced was the SCSI controller. After
that there were still hardware "hanging" and eventually the system
engineers replaced the whole server and they weren't sure what the fault
was. The lost transactions happened not on the first server hang. I'm
more curious to know why the transactions in the middle got lost but the
last transaction was there.
Thanks,
lec