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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: Alfred Perlstein <bright(at)wintelcom(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: Re[4]: Allowing WAL fsync to be done via O_SYNC
Date: 2001-03-16 21:59:42
Message-ID: 27958.984779982@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
>> 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.

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.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-03-16 22:05:04 Re: problems with startup script on upgrade
Previous Message Tom Lane 2001-03-16 21:58:30 Re: problems with startup script on upgrade