Re: Losing records when server hang
От | lec |
---|---|
Тема | Re: Losing records when server hang |
Дата | |
Msg-id | 411824EB.40407@streamyx.com обсуждение исходный текст |
Ответ на | Re: Losing records when server hang ("Scott Marlowe" <smarlowe@qwest.net>) |
Ответы |
Re: Losing records when server hang
|
Список | pgsql-general |
Scott Marlowe wrote:
I'm not sure.On Mon, 2004-08-09 at 09:07, lec wrote:Scott Marlowe wrote:On Sun, 2004-08-08 at 21:26, Alvaro Herrera Munoz wrote:On Sun, Aug 08, 2004 at 08:36:36PM -0600, Scott Marlowe wrote:On Sun, 2004-08-08 at 19:43, lec wrote: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.I'm using Redhat 7.3, kernel 2.4.18It is actually possible if he uses several backends to do the job, and transaction inserting record 10 commits before the hang, and 5,6,7,8,9 don't.Just 1 backend.Yeah, but he explicitly said he'd committed 1 through 10. Unless he didn't understand what is meant by commit. I.e. committing AND receiving the ack for that commit. Until the database says it committed, nothing's been committed, so he might have thought just firing the insert query was committing. I hadn't really thought of that angle. Is that the case, lec?I explicitly 'COMMIT'If this is only one backend, then I'd love to see how did he do that.Me too :-)That's exactly leaving me puzzled. I don't know if it has anything to do with the SCSI controller or hardware related stuff. The controller is a RAID, configured are RAID-5.Does that RAID controller have NON battery backed cache?
В списке pgsql-general по дате отправления: