From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Larry Rosenman <ler(at)lerctr(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) |
Date: | 2000-11-16 20:02:22 |
Message-ID: | 200011162002.PAA26639@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> * Don Baccus <dhogaza(at)pacifier(dot)com> [001116 13:46]:
> > At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote:
> >
> > >> I think the default should probably be no delay, and the documentation
> > >> on enabling this needs to be clear and obvious (i.e. hard to miss).
> > >
> > >I just talked to Tom Lane about this. I think a sleep(0) just before
> > >the flush would be the best. It would reliquish the cpu slice if
> > >another process is ready to run. If no other backend is running, it
> > >probably just returns. If there is another one, it gives it a chance to
> > >complete. On return from sleep(0), it can check if it still needs to
> > >flush. This would tend to bunch up flushers so they flush only once,
> > >while not delaying cases where only one backend is running.
> >
> > 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.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Larry Rosenman | 2000-11-16 20:04:03 | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) |
Previous Message | Bruce Momjian | 2000-11-16 19:53:07 | Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) |