AW: AW: Re[4]: Allowing WAL fsync to be done via O_SYNC

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alfred Perlstein <bright(at)wintelcom(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: AW: AW: Re[4]: Allowing WAL fsync to be done via O_SYNC
Date: 2001-03-19 12:15:52
Message-ID: 11C1E6749A55D411A9670001FA687963368253@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> >> It's great as long as you never block, but it sucks for making things
> >> wait, because the wait interval will be some multiple of 10 msec rather
> >> than just the time till the lock comes free.
>
> > On the AIX platform usleep (3) is able to really sleep microseconds without
> > busying the cpu when called for more than approx. 100 us (the longer the interval,
> > the less busy the cpu gets) .
> > Would this not be ideal for spin_lock, or is usleep not very common ?
> > Linux sais it is in the BSD 4.3 standard.
>
> HPUX has usleep, but the man page says
>
> The usleep() function is included for its historical usage. The
> setitimer() function is preferred over this function.

I doubt that setitimer has microsecond precision on HPUX.

> In any case, I would expect that all these functions offer accuracy
> no better than the scheduler's regular clock cycle (~ 100Hz) on most
> kernels.

Not on AIX, and I don't beleive that for the majority of other UNIX platforms eighter.
I do however suspect, that some implementations need a busy loop, which would,
if at all, only be acceptable on an SMP system.

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rod Taylor 2001-03-19 12:28:21 Fw: [vorbis-dev] ogg123: shared memory by mmap()
Previous Message Alexander Klimov 2001-03-19 11:47:37 Re: Re: problems with startup script on upgrade