Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
От | Bruce Momjian |
---|---|
Тема | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) |
Дата | |
Msg-id | 200011162027.PAA28316@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) (Larry Rosenman <ler@lerctr.org>) |
Список | pgsql-hackers |
> * Bruce Momjian <pgman@candle.pha.pa.us> [001116 14:02]: > > > > This sounds like an interesting approach, yes. > > > Question: Is sleep(0) guaranteed to at least give up control? > > > > > > The way I read my UnixWare 7's man page, it might not, since alarm(0) > > > just cancels the alarm... > > > > Well, it certainly is a kernel call, and most OS's re-evaluate on kernel > > call return. > BUT, do we know for sure that sleep(0) is not optimized in the library > to just return? We can only do our best here. I think guessing whether other backends are _about_ to commit is pretty shaky, and sleeping every time is a waste. This seems the cleanest. Funny you should mention the optimization. I just checked BSDI and saw:u_intsleep(secs) u_int secs;{ struct timevalnt, ot; long diff; int rc; if (secs == 0) return (0); So maybe we need another _fake_ kernel call, or a select/usleep with a very small value. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: