> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Other backend will see they are not the lowest
> > > WAIT_ON_FSYNC and will wait for their byte to be set to NOT_IN_COMMIT
> > > so they can then continue, knowing their data was synced.
> >
> > How will they wait? Without a semaphore involved, your answer must
> > be either "timed sleep" or "busy-wait loop", neither of which is
> > attractive ...
>
> Yes, either timed sleep or busy-wait. One nifty trick would be for each
> backend that is not going to do the fsync to just sleep with signals
> enabled, and for the fsyncing backend to signal the other backends to
> exit their sleep. That way, only one backend does the checking.
>
> This sleep thing was going to be a problem anyway with the old system.
> At least this way, they sleep/check only in cases where it is valuable.
I have another idea. If a backend gets to the point that it needs
fsync, and there is another backend in START_LOG_WRITE, it can go to an
interuptable sleep, knowing another backend will perform the fsync and
wake it up. Therefore, there is no busy-wait or timed sleep.
Of course, a backend must set its status to WAIT_ON_FSYNC to avoid a
race condition.
-- 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
