Bruce Momjian [EMAIL PROTECTED] writes:
Not sure how we are going to do this in Win32, but somehow we will have
to record all open files between checkpoints in an area that the
checkpoint process can read during a checkpoint.
One reason I like the idea of adopting a sync-when-you-write policy
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
One reason I like the idea of adopting a sync-when-you-write policy is
that it eliminates the need for anything as messy as that.
Yes, but can we do it without causing a performance degredation, and I
would hate to change something to
Tom Lane wrote:
Seriously though, if we can move the bulk of the writing work into
background processes then I don't believe that there will be any
significant penalty for regular backends. And I believe that it would
be a huge advantage from a correctness point of view if we could stop
Manfred Spraul [EMAIL PROTECTED] writes:
Which function guarantees that renames of WAL files arrived on the disk?
The OS itself is supposed to guarantee that; that's what a journaling
file system is for. In any case, I don't think we care. Renaming would
apply only to WAL segments that are
Manfred Spraul wrote:
Tom Lane wrote:
Seriously though, if we can move the bulk of the writing work into
background processes then I don't believe that there will be any
significant penalty for regular backends. And I believe that it would
be a huge advantage from a correctness point of view
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
One reason I like the idea of adopting a sync-when-you-write policy is
that it eliminates the need for anything as messy as that.
Yes, but can we do it without causing a performance degredation, and I
would hate
Jan Wieck [EMAIL PROTECTED] writes:
Well, the bgwriter has basically the same chance the checkpointer has
... mdblindwrt() in the end, because he doesn't have the relcache handy.
We could easily get rid of mdblindwrt --- there is no very good reason
that we use the relcache for I/O. There
