Re: Allowing WAL fsync to be done via O_SYNC

From: Alfred Perlstein <bright(at)wintelcom(dot)net>
To: Larry Rosenman <ler(at)lerctr(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "William K(dot) Volkman" <wkv(at)hiscorp(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Allowing WAL fsync to be done via O_SYNC
Date: 2001-03-18 22:48:31
Message-ID: 20010318144830.P29888@fw.wintelcom.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Larry Rosenman <ler(at)lerctr(dot)org> [010318 14:17] wrote:
> * Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [010318 14:55]:
> > Alfred Perlstein <bright(at)wintelcom(dot)net> writes:
> > >> Just by making a thread call libc changes personality to use thread
> > >> safe routines (I.E. add mutex locking). Use one thread feature, get
> > >> the whole set...which may not be that bad.
> >
> > > Actually it can be pretty bad. Locked bus cycles needed for mutex
> > > operations are very, very expensive, not something you want to do
> > > unless you really really need to do it.
> >
> > It'd be interesting to try to get some numbers about the actual cost
> > of using a thread-aware libc, on platforms where there's a difference.
> > Shouldn't be that hard to build a postgres executable with the proper
> > library and run some benchmarks ... anyone care to try?
> I can get the code compiled, but don't have the skills to generate
> a test case worthy of anything....

There's a 'make test' or something ('regression' maybe?) target that
runs a suite of tests on the database, you could use that as a
bench/timer, you could also try mysql's "crashme" script.

--
-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-03-18 23:45:52 Re: new version of contrib-intarray
Previous Message Larry Rosenman 2001-03-18 22:15:06 Re: Allowing WAL fsync to be done via O_SYNC