ITAGAKI Takahiro wrote:
The only thing I don't understand is the naming of 'checkpoint_smoothing'.
Can users imagine the unit of 'smoothing' is a fraction?
You explain the paremeter with the word 'fraction'.
Why don't you simply name it 'checkpoint_fraction' ?
| Specifies the target length of
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I added a spinlock to protect the signaling fields between bgwriter and
backends. The current non-locking approach gets really difficult as the
patch adds two new flags, and both are more important than the existing
ckpt_time_warn
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
In fact, I think there's a small race condition in CVS HEAD:
Yeah, probably --- the original no-locking design didn't have any side
flags. The reason you need the lock is for a backend to be sure that
a newly-started checkpoint is
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
I tend to agree with whoever said upthread that the combination of GUC
variables proposed here is confusing and ugly. It'd make more sense to
have min and max checkpoint rates in KB/s, with the max checkpoint rate
only honored when
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
I tend to agree with whoever said upthread that the combination of GUC
variables proposed here is confusing and ugly. It'd make more sense to
have min and max checkpoint rates in KB/s, with the max checkpoint rate
Heikki Linnakangas [EMAIL PROTECTED] writes:
I don't think you understand how the settings work. Did you read the
documentation? If you did, it's apparently not adequate.
I did read the documentation, and I'm not complaining that I don't
understand it. I'm complaining that I don't like the
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
The main tuning knob is checkpoint_smoothing, which is defined as a
fraction of the checkpoint interval (both checkpoint_timeout and
checkpoint_segments are taken into account). Normally, the write phase
of a checkpoint takes
Simon Riggs [EMAIL PROTECTED] writes:
Completed all of the agreed changes for TG:
I've just realized that there's a fatal problem with this design.
We've now got tqual.c setting page LSN when it holds only share lock
on the buffer. That will absolutely not work, eg two backends might
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
So the question is, why in the heck would anyone want the behavior that
checkpoints take exactly X time??
Because it's easier to tune. You don't need to know how much checkpoint
I/O you can tolerate. The system will use just
On Wed, 2007-06-20 at 15:51 -0700, Neil Conway wrote:
Attached is a patch that fixes this, by calling fflush() on the psql
output stream after each call to printQuery() in ExecQueryUsingCursor().
Applied to HEAD.
-Neil
---(end of broadcast)---
Neil Conway [EMAIL PROTECTED] writes:
On Wed, 2007-06-20 at 15:51 -0700, Neil Conway wrote:
Attached is a patch that fixes this, by calling fflush() on the psql
output stream after each call to printQuery() in ExecQueryUsingCursor().
Applied to HEAD.
Seems reasonable to back-patch into 8.2
ITAGAKI Takahiro [EMAIL PROTECTED] wrote:
Here is a patch that cancels autovacuum workers conflicting with
DROP TABLE, TRUNCATE and CLUSTER. It was discussed here:
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00556.php
I made an adjustment for the latest 'more autovacuum fixes'
On Thu, 2007-21-06 at 22:09 -0400, Tom Lane wrote:
Seems reasonable to back-patch into 8.2 too...
Okay, done.
-Neil
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
13 matches
Mail list logo
