Re: WAL fsync scheduling

> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(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