On Thu, 29 Mar 2007, Magnus Hagander wrote:
I've included a couple of more counters per ideas from Greg Smith in his
logging patch.
I just submitted a patch that logs the remaining things of value from my
original that couldn't be derived from the information you're collecting.
Between them
Greg Smith wrote:
On Thu, 29 Mar 2007, Magnus Hagander wrote:
I've included a couple of more counters per ideas from Greg Smith in his
logging patch.
I just submitted a patch that logs the remaining things of value from my
original that couldn't be derived from the information you're
On Sun, 1 Apr 2007, Magnus Hagander wrote:
The data in pg_stat_bgwriter certainly doesn't update *during* a
checkpoint, if that's what you're saying.
Scratch previous message, replace with dude ur code rulez!
I was working on the assumption it was possible to get a partial result
because I
Magnus Hagander [EMAIL PROTECTED] writes:
Attached is a new version of the bgwriter stats patch. Per previous
discussion, now uses the stats system only. Introduces a new stats message
for bgwriter, and also introduces a global stats part of the stats file
for statistics not bound to a
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Attached is a new version of the bgwriter stats patch. Per previous
discussion, now uses the stats system only. Introduces a new stats message
for bgwriter, and also introduces a global stats part of the stats file
for statistics not
Magnus Hagander [EMAIL PROTECTED] writes:
This seems quite a bizarre way to do things. Why wouldn't you implement
this functionality by shipping messages to the stats collector?
Would you suggest doing the same with the checkpoint counter, that's already
in shared mem? I want to expose that
Magnus Hagander wrote:
Anyway. Attached patch adds this to the bgwriter shared memory. Is it
safe to do this, and then just have a regular function running in a
normal backend pulling out the value and returning it to the user,
without locking?
If the variable is an int64, I don't believe so:
Neil Conway wrote:
Magnus Hagander wrote:
Anyway. Attached patch adds this to the bgwriter shared memory. Is it
safe to do this, and then just have a regular function running in a
normal backend pulling out the value and returning it to the user,
without locking?
If the variable is an int64,
Magnus Hagander wrote:
Ok. But it should be safe if it's int32?
You should probably use sig_atomic_t, to be safe. Although I believe
that read/writes to int are atomic on most platforms, in any case.
Actually, since it's just statistics data, it wouldn't be a problem that
it's not atomic,
Neil Conway wrote:
Magnus Hagander wrote:
Ok. But it should be safe if it's int32?
You should probably use sig_atomic_t, to be safe. Although I believe
that read/writes to int are atomic on most platforms, in any case.
Ok. That's an easy enough change.
Actually, since it's just
Magnus Hagander [EMAIL PROTECTED] writes:
I want to be able to pull some stats out of the bgwriter to be able to
track things. One thing is the total number of buffers written out.
Other things are the number of checkpoints and such.
Anyway. Attached patch adds this to the bgwriter shared
Magnus Hagander [EMAIL PROTECTED] writes:
Neil Conway wrote:
I don't think that's the right attitude to take, at all. Why not just
use a lock? It's not like the overhead will be noticeable.
Probably, but none of the other code appears to take a lock out on it :)
Huh? It doesn't use a lock
On Monday 19 March 2007 15:32, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
I want to be able to pull some stats out of the bgwriter to be able to
track things. One thing is the total number of buffers written out.
Other things are the number of checkpoints and such.
Tom Lane wrote:
This seems quite a bizarre way to do things. Why wouldn't you implement
this functionality by shipping messages to the stats collector?
Would that have any benefits over the shmem approach?
-Neil
---(end of broadcast)---
Neil Conway [EMAIL PROTECTED] writes:
Tom Lane wrote:
This seems quite a bizarre way to do things. Why wouldn't you implement
this functionality by shipping messages to the stats collector?
Would that have any benefits over the shmem approach?
Well, for one thing, it would fit naturally
15 matches
Mail list logo
