AW: AW: Re[4]: Allowing WAL fsync to be done via O_SYNC
От | Zeugswetter Andreas SB |
---|---|
Тема | AW: AW: Re[4]: Allowing WAL fsync to be done via O_SYNC |
Дата | |
Msg-id | 11C1E6749A55D411A9670001FA687963368253@sdexcsrv1.f000.d0188.sd.spardat.at обсуждение исходный текст |
Ответы |
Re: AW: AW: Re[4]: Allowing WAL fsync to be done via O_SYNC
|
Список | 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
В списке pgsql-hackers по дате отправления: