Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > As far as #2, my posted proposal was to write the full pages to WAL when
> > they are written to the file system, and not when they are first
> > modified in the shared buffers ---
>
> That is *completely* unworkable. Or were you planning to abandon the
> promise that a transaction is committed when we have flushed its WAL
> commit record?
"completely" is a strong word.
What is on disk at the time the page is modified in the shared buffer is
just fine for recovery (it is the same as what we write to WAL anyway).
It is just when the page gets written to disk that it changes for
recovery, so potentially during recovery you could take what is on disk,
modify it by reading WAL, then replace it later with the image from WAL.
The only problem I see is that the page might be partially written and
WAL modifications to the page might fail but later the page will be
replaced anyway. Perhaps we could record pages that are corrupt
(hopefully only one) and make sure later page images replace them, or we
fail on recovery.
> > Seems it is similar to fsync in risk, which is not a new option.
>
> The point here is that fsync-off is only realistic for development
> or playpen installations. You don't turn it off in a production
> machine, and I can't see that you'd turn off the full-page-write
> option either. So we have not solved anyone's performance problem.
Yes, this is basically another fsync-like option that isn't for
production usage in most cases. Sad but true.
-- 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