Added to TODO:
* Delay fsync() when other backends are about to commit too
[ Charset ISO-8859-1 unsupported, converting... ]
BUT, do we know for sure that sleep(0) is not optimized in
the library to just return?
We can only do our best here. I think guessing whether other
Ok, so with CHECKPOINTS, we could move the offline log files to
somewhere else so that we could archive them, in my
undertstanding. Now question is, how we could recover from disaster
like losing every table files except log files. Can we do this with
WAL? If so, how can we do it?
At 07:05 PM 11/19/00 +0100, [EMAIL PROTECTED] wrote:
Cam I ask what BAR is ?
Backup and recovery, presumably...
- Don Baccus, Portland OR [EMAIL PROTECTED]
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
* Bruce Momjian [EMAIL PROTECTED] [001117 11:39]:
* Bruce Momjian [EMAIL PROTECTED] [001117 11:23]:
sleep(3) should conform to POSIX specification, if anyone has the
reference they can check it to see what the effect of sleep(0)
should be.
Yes, but Posix also specifies
At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote:
I think the default should probably be no delay, and the documentation
on enabling this needs to be clear and obvious (i.e. hard to miss).
I just talked to Tom Lane about this. I think a sleep(0) just before
the flush would be the best. It
* Don Baccus [EMAIL PROTECTED] [001116 13:46]:
At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote:
I think the default should probably be no delay, and the documentation
on enabling this needs to be clear and obvious (i.e. hard to miss).
I just talked to Tom Lane about this. I think a
At 09:32 AM 11/16/00 -0800, Alfred Perlstein wrote:
* Bruce Momjian [EMAIL PROTECTED] [001116 08:59] wrote:
Ewe, so we have this 1/200 second delay for every transaction. Seems
bad to me.
I think as long as it becomes a tunable this isn't a bad idea at
all. Fixing it at 1/200 isn't
At 09:32 AM 11/16/00 -0800, Alfred Perlstein wrote:
* Bruce Momjian [EMAIL PROTECTED] [001116 08:59] wrote:
Ewe, so we have this 1/200 second delay for every transaction. Seems
bad to me.
I think as long as it becomes a tunable this isn't a bad idea at
all. Fixing it at 1/200 isn't so great
* Bruce Momjian [EMAIL PROTECTED] [001116 11:59] wrote:
At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote:
I think the default should probably be no delay, and the documentation
on enabling this needs to be clear and obvious (i.e. hard to miss).
I just talked to Tom Lane about this.
In OS kernel design, you try to avoid process herding bottlenecks.
Here, we want them herded, and giving up the CPU may be the best way to
do it.
Yes, but if everyone yeilds you're back where you started, and with
128 or more backends do you really want to cause possibly that many
Bruce Momjian writes:
The way I read my UnixWare 7's man page, it might not, since alarm(0)
just cancels the alarm...
Well, it certainly is a kernel call, and most OS's re-evaluate on kernel
call return.
In glibc, sleep(0) just does "return 0;", so if the compiler has a good
day the
Alfred Perlstein [EMAIL PROTECTED] writes:
It might make more sense to keep a private copy of the last time
the file was modified per-backend by that particular backend and
a timestamp of the last fsync shared globally so one can forgo the
fsync if "it hasn't been dirtied by me since the last
* Tom Lane [EMAIL PROTECTED] [001116 13:31] wrote:
Alfred Perlstein [EMAIL PROTECTED] writes:
It might make more sense to keep a private copy of the last time
the file was modified per-backend by that particular backend and
a timestamp of the last fsync shared globally so one can forgo the
* Bruce Momjian [EMAIL PROTECTED] [001116 12:31] wrote:
In OS kernel design, you try to avoid process herding bottlenecks.
Here, we want them herded, and giving up the CPU may be the best way to
do it.
Yes, but if everyone yeilds you're back where you started, and with
128 or
You are going to kernel call/yield anyway to fsync, so why
not try and if someone does the fsync, we don't need to do it.
I am suggesting re-checking the need for fsync after the return
from sleep(0).
It might make more sense to keep a private copy of the last time
the file was
No. Checkpoints are to speedup after crash recovery and
to remove/archive log files. With WAL server doesn't write
any datafiles on commit, only commit record goes to log
(and log fsync-ed). Dirty buffers remains in memory long
Ok, so with CHECKPOINTS, we could move the offline
At 02:13 PM 11/16/00 -0500, Bruce Momjian wrote:
I think the default should probably be no delay, and the documentation
on enabling this needs to be clear and obvious (i.e. hard to miss).
I just talked to Tom Lane about this. I think a sleep(0) just before
the flush would be the best.
I am just suggesting that instead of flushing the log on every
transaction end, just do it every X seconds.
Or maybe more practical is, when the log buffer fills.
And of course during checkpoints.
Also before backend's going to write dirty buffer from pool
to system cache - changes must
Earlier, Vadim was talking about arranging to share fsyncs of the WAL
log file across transactions (after writing your commit record to the
log, sleep a few milliseconds to see if anyone else fsyncs before you
do; if not, issue the fsync yourself). That would offer less-than-
* Tatsuo Ishii [EMAIL PROTECTED] [001110 18:42] wrote:
Yes, though we can change this. We also can implement now
feature that Bruce wanted so long and so much -:) -
fsync log not on each commit but each ~ 5sec, if
losing some recent commits is acceptable.
Sounds great.
Bruce Momjian [EMAIL PROTECTED] writes:
I have to agree with Alfred here: this does not sound like a feature,
it sounds like a horrid hack. You're giving up *all* consistency
guarantees for a performance gain that is really going to be pretty
minimal in the WAL context.
It does not give up
* Bruce Momjian [EMAIL PROTECTED] [00 00:16] wrote:
* Tatsuo Ishii [EMAIL PROTECTED] [001110 18:42] wrote:
Yes, though we can change this. We also can implement now
feature that Bruce wanted so long and so much -:) -
fsync log not on each commit but each ~ 5sec, if
Bruce Momjian [EMAIL PROTECTED] writes:
Not really, I thought an ack on a commit would mean that the data
is actually in stable storage, breaking that would be pretty bad
no?
The default is to sync on commit, but we need to give people options of
several seconds delay for performance
Can you tell me how to use CHECKPOINT please?
You shouldn't normally use it - postmaster will start backend
each 3-5 minutes to do this automatically.
Oh, I see.
Is this the same as a SAVEPOINT?
No. Checkpoints are to speedup after crash recovery and
to remove/archive log
* Tatsuo Ishii [EMAIL PROTECTED] [001110 18:42] wrote:
Yes, though we can change this. We also can implement now
feature that Bruce wanted so long and so much -:) -
fsync log not on each commit but each ~ 5sec, if
losing some recent commits is acceptable.
Sounds great.
Not really,
New CHECKPOINT command.
Auto removing of offline log files and creating new file
at checkpoint time.
Can you tell me how to use CHECKPOINT please?
You shouldn't normally use it - postmaster will start backend
each 3-5 minutes to do this automatically.
Is this the same as a
New CHECKPOINT command.
Auto removing of offline log files and creating new file
at checkpoint time.
Can you tell me how to use CHECKPOINT please?
Is this the same as a SAVEPOINT?
No. Checkpoints are to speedup after crash recovery and
to remove/archive log files. With WAL server
27 matches
Mail list logo
