Thread

1. Re: [HACKERS] Update on my 6.4.2 progress

   Tom Lane <tgl@sss.pgh.pa.us> — 1999-06-20T23:22:39Z

   Wayne Piekarski <wayne@senet.com.au> writes:
   > I already have the -o -F switch in the startup file (which I believe is
   > working) but I'm under the impression from what I read that there are two
   > fsync's - one you can switch off, and one which is fixed into the code
   > and possibly can't be removed?
   
   No.  I've looked.
   
   Actually there is an un-disablable fsync() on the error file in elog.c,
   but it's not invoked under ordinary scenarios as far as I can tell,
   and it shouldn't be a performance bottleneck anyway.  *All* the ordinary
   uses of fsync go through pg_fsync.
   
   			regards, tom lane
   
   

2. Re: [HACKERS] Update on my 6.4.2 progress

   Wayne Piekarski <wayne@senet.com.au> — 1999-06-21T09:00:48Z

   > Wayne Piekarski <wayne@senet.com.au> writes:
   > > I already have the -o -F switch in the startup file (which I believe is
   > > working) but I'm under the impression from what I read that there are two
   > > fsync's - one you can switch off, and one which is fixed into the code
   > > and possibly can't be removed?
   > 
   > No.  I've looked.
   > 
   > Actually there is an un-disablable fsync() on the error file in elog.c,
   > but it's not invoked under ordinary scenarios as far as I can tell,
   > and it shouldn't be a performance bottleneck anyway.  *All* the ordinary
   > uses of fsync go through pg_fsync.
   
   I had a dig through the source code yesterday and witnessed the same thing
   as well, each call is controlled with -F. However, I did mess up when I
   wrote my previous email though, because I don't have -F enabled right now,
   so I am running with the fsync() turned on, which makes sense and explains
   what is happening with the cache. 
   
   After reading the mailing list I was under the impression this fsyncing
   was different from the one controlled by -F.
   
   I am going to be taking it for a test tonight with -F enabled to observe
   how much better the performance is. Hopefully it will cache better as a
   result of this, I guess I'll have to run it like this from now on.
   
   thanks,
   Wayne
   
   ------------------------------------------------------------------------------
   Wayne Piekarski                               Tel:     (08) 8221 5221
   Research & Development Manager                Fax:     (08) 8221 5220
   SE Network Access Pty Ltd                     Mob:     0407 395 889
   222 Grote Street                              Email:   wayne@senet.com.au
   Adelaide SA 5000                              WWW:     http://www.senet.com.au