Andrew Dunstan wrote:
Is this what broke the regression tests on HEAD?
Yes, it is -- fix checked in to HEAD. My apologies for missing this.
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscr
Is this what broke the regression tests on HEAD?
cheers
andrew
Neil Conway wrote:
Tom Lane wrote:
If the stats collector gets sufficiently backed up, you will lose
messages. [...] Please do not try to make piecemeal changes in that
basic design decision.
Fair enough.
> (Actually, we could skinny
Certainly seems that way. Missed a .diff for the rules output there...
Should be a simple replace, from what I can tell what's in the output on
the buildfarm boxes I checked is correct, the expected file shuold
changed.
Oops.
//Magnus
>
> Is this what broke the regression tests on HEAD?
>
> c
Tom Lane wrote:
If the stats collector gets sufficiently backed up, you will lose
messages. [...] Please do not try to make piecemeal changes in that
basic design decision.
Fair enough.
> (Actually, we could skinny it down to backend PID only ...
but that would add a hashtable lookup to every mess
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'd vote against that. The mechanism is lossy by design
> Is it _lossy_, or merely unordered? While UDP doesn't guarantee message
> delivery, I wonder what kind of extreme circumstances would need to
> exist for you to lose UDP packet
Tom Lane wrote:
I'd vote against that. The mechanism is lossy by design
Is it _lossy_, or merely unordered? While UDP doesn't guarantee message
delivery, I wonder what kind of extreme circumstances would need to
exist for you to lose UDP packets outright over the loopback interface.
> I don't t
Neil Conway <[EMAIL PROTECTED]> writes:
> How about changing the statistics collector so that we only include a
> row in the statistics view when we receive the BESTART message?
I'd vote against that. The mechanism is lossy by design and so we
must design on the assumption that we will sometimes
Tom Lane wrote:
I think this argument is a red herring ... or at least it leads in a
direction I find unacceptable.
I agree -- I was just pointing out the reason that, in the current
design, there is cause to do things as Magnus' original patch did.
We are already transmitting three more fields t
Neil Conway <[EMAIL PROTECTED]> writes:
> On adapting the code to just send the client address in the BE start
> message, I'm not actually sure this is the right way to go. The problem
> is that stats messages are unordered -- so we might receive, say, an
> activity message for a backend before
Magnus Hagander wrote:
I guess that's from not reading things carefully enough. I looked for
where "backend pid" was transmitted, because I thought that would be a
good place to put it.
On adapting the code to just send the client address in the BE start
message, I'm not actually sure this is the
Neil Conway <[EMAIL PROTECTED]> writes:
> - Is the backend startup time sensitive information? Considering this
> information is available via ps(1), perhaps it would be better to allow
> any user to see any backend's startup time, rather than providing a
> false sense of security.
Remote datab
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> I guess that's from not reading things carefully enough. I looked for
> where "backend pid" was transmitted, because I thought that would be a
> good place to put it. Which might bring up the question, why are things
> like the backend pid sent in msg
>> Updated patch attached.
>
>A few more comments:
>
>- why did you add the client address to PgStat_MsgHdr, rather than
>PgStat_MsgBestart? It would be nice to avoid sending the
>client address
>for each and every stats message, as it shouldn't change over the life
>of the session.
I guess th
Magnus Hagander wrote:
Updated patch attached.
A few more comments:
- why did you add the client address to PgStat_MsgHdr, rather than
PgStat_MsgBestart? It would be nice to avoid sending the client address
for each and every stats message, as it shouldn't change over the life
of the session.
-
> > Looks pretty good -- barring any objections I'll apply this to HEAD
> > tomorrow or the day after (there's a room for a bit of
> cleanup to the
> > docs, but I'll do that before committing).
>
> Couple of minor gripes:
>
> 1. Can we reduce the amount of stuff #include'd by pgstat.h?
> I
Neil Conway <[EMAIL PROTECTED]> writes:
> Looks pretty good -- barring any objections I'll apply this to HEAD
> tomorrow or the day after (there's a room for a bit of cleanup to the
> docs, but I'll do that before committing).
Couple of minor gripes:
1. Can we reduce the amount of stuff #inclu
Magnus Hagander wrote:
* Add session start time and last statement time to pg_stat_activity
(we already had last-statement-time, provided command string stats were
enabled)
* Add the client IP address and port to pg_stat_activity
Looks pretty good -- barring any objections I'll apply this to HEAD
This patch ticks off the following TODO items:
* Add session start time and last statement time to pg_stat_activity
(we already had last-statement-time, provided command string stats were
enabled)
* Add the client IP address and port to pg_stat_activity
I have tested on Linux (both IPV4 and Uni
18 matches
Mail list logo
