Re: WAL fsync scheduling

> > 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