Shridhar Daithankar wrote:
> Bruce Momjian wrote:
>
> > Shridhar Daithankar wrote:
> >>I can not see why writing an 8K block is any more safe than writing just the
> >>changes.
> >>
> >>I may be dead wrong but just putting my thoughts together..
> > The problem is that we need to record what was on the page before we
> > made the modification because there is no way to know that a write
> > hasn't corrupted some part of the page.
>
> OK... I think there is hardly any way around the fact that we need to flush a
> page the way we do it now. But that is slow. So what do we do.
>
> How feasible it would be to push fsyncing those pages/files to background writer
> and have it done on priority? That way the disk IO wait could get out of
> critical execution path. May be that could yield the performance benefit we are
> looking for.
We already allow committing transactions to flush WAL. We don't do the
flush when we write the page image to WAL, unless we can't get any other
buffer and have to write it ourselves and it hasn't already been
fsync'ed by another transaction. This is where the current LSN come in ---
it tells us how far fsync has gone, and each page has an LSN that tells
us when it was written to WAL.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
