> >Yes. It is not a problem that a give transaction aborts while it is
> >being done because it couldn't have been marked as completed, but the
> >previous transaction was marked as completed, and only some blocks could
> >be on the disk.
>
> OK, this was what I suspected, and of course is the intuitively
> obvious scenario.
>
> In other words, "-F" considered - and proven! - harmful :)
>
> >I hope for every release. I tried to propose some solutions, but
> >couldn't code it.
>
> There was a bit of discussion about the cause of the problem
> in this list earlier, so part of my re-raising it was an attempt
> to encourage more discussion. Not that I know enough about the
> code to be of any help, I'm afraid. When I first learned of
> this problem (via my own experimentation) I dug around a bit
> and it became clear that it wasn't obvious. I.E. the disk
> cache knows about dirty/not dirty buffers and takes great
> care to only flush dirty ones, that level of stuff. When I
> heard that updating pg_log was apparently involved I realized
> it was more of a higher-level than lower-level problem.
>
> Sigh...
>
> Or am I wrong?
Writing the buffers to a file, and making sure they are on the disk are
different issues. Also, fsync only comes into play in an OS crash, so
if that only happens once a year, and you are willing to restore from
tape in that case (or check the integrity of the data on reboot), -F
may be fine.
-- Bruce Momjian | http://www.op.net/~candle maillist@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