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.18
> > > It 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?