Re: Datatypes and performance

From: "Lincoln Yeoh" <lyeoh@pop.jaring.my>
> Just because all reported commits go in doesn't mean there won't be any
> data loss.

Ok, but I am only talking about the database here... I am not counting in the possibility of hardware failure as a
resultof the power failure. That would be a non-recoverable error, just as if the city got nuked or the house burnt
downto the ground... In those cases i have to rebuild the hardware and restore from a remote backup (daily backups over
thenet to another city) and lose one days work. 

> If you pull the power cord, the DB should be in a consistent state barring
> hardware and other issues. However there can be data loss, because the
> clients might have been inserting data which may not be able to be
> reproduced again, but which was not committed nor reported as committed,
> and the clients may no longer have a copy of the data. So how does the app
> or user deal with that? That can determine if data is lost holistically.

No problem. I leave it to the client/user to ensure that data does not get lost at the client side until the backend
reportsit as committed. The client has to be responsible for the data until is has successfully handed it over to the
dbserver. 
When the db server has got the data, it is responsible for it, except in the case of hardware failures.

> Given I've seen lots of things not work as they should, 100% guarantees
> seem like wishful thinking. I'd just believe that with Fsync on, the
> probability of commits being saved to disk is very high. Whereas with fsync
> off, the probability is a lot lower especially if the O/S is prone to
> taking 30 seconds or longer to sync outstanding data to disk.

Ok, maybe I'll have to turn it on again, then... I thought the journal was fsynced anyway, and that the Fsync option
onlywas for old-style table file syncing... 


/* m */

>
> Regards,
> Link.
>
> At 05:11 PM 7/7/2003 +0200, Mattias Kregert wrote:
>
> > > > If I turn fsync on and then pull the power cord while a
> > > > number of clients are doing lots of inserts/updates and stuff,
> > > > will the fsync then guarantee that no data will be lost or
> > > > corrupted?
> > > You are surely kidding, aren't you ?
> > >
> > > Karsten
> >
> >No. No kidding.
> >Just to clarify, what I mean is: With FSYNC enabled, after a power
> >failure, after "pg_ctl start" and replay of xact log etc; Are COMMITTED
> >transactions guaranteed to be intact, and are UNCOMMITTED transactions
> >guaranteed not to appear in the tables?
> >
> >If the answer is "yes", then I understand the use of FSYNC.
> >
> >If the answer is "no", then i don't see the point in using FSYNC at all.
> >
> >/* m */
> >
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
>