> > Bruce Momjian <[EMAIL PROTECTED]> 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
  [EMAIL PROTECTED]               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Reply via email to