Tom Lane <[EMAIL PROTECTED]> writes:
> Doug McNaught <[EMAIL PROTECTED]> writes:
> > In my understanding, it means "all currently dirty blocks in the file
> > cache are queued to the disk driver". The queued writes will
> > eventually complete, but not necessarily before sync() returns. I
> >
Doug McNaught <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> In practice I am not sure there is a problem. The local man page for
>> sync() says
>>
>> The writing, although scheduled, is not necessarily complete upon
>> return from sync.
>>
>> Now if "scheduled" means "wi
Tom Lane <[EMAIL PROTECTED]> writes:
> In practice I am not sure there is a problem. The local man page for
> sync() says
>
> The writing, although scheduled, is not necessarily complete upon
> return from sync.
>
> Now if "scheduled" means "will occur before any subsequently-command
Mats Lofkvist <[EMAIL PROTECTED]> writes:
> [ mdsync is ugly and not completely reliable ]
Yup, it is. Do you have a better solution?
fsync is not the answer, since the checkpoint process has no way to know
what files may have been touched since the last checkpoint ... and even
if it could find
[EMAIL PROTECTED] (Tom Lane) writes:
[snip]
> On a filesystem that does have that kind of problem, can't you avoid it
> just by using O_DSYNC on the WAL files? Then there's no need to call
> fsync() at all, except during checkpoints (which actually issue sync()
> not fsync(), anyway).
This comm
