On Sun, 2005-06-26 at 20:52 +0200, Petr Jelínek wrote:
> Alvaro Herrera wrote:
>
> >I don't think this approach is very user-friendly. I'd vote for the
> >catalog approach, I think.
> >
> >
> Ok I am fine with both but catalog changes would mean more hacking of
> ALTER DATABASE and ALTER USER.
Neil Conway <[EMAIL PROTECTED]> writes:
> - when we read in the stats collector's stats file in a normal backend,
> there will be no pgStatDBHash entry for the backend's database.
> Therefore we'll read the beentry for the backend, and when we go to
> increment the n_backends for the correspondi
So now I have it all working including brand new alter database (this
would have to be doublechecked by somebody from core team) and using
proc array to get number of backends per database and per user.
My only concer now is that userid in PGPROC, does anybody have anything
against it ?
And
Tom Lane wrote:
(d) is a performance bug, but if there is a functionality bug I'm not
seeing it.
You must use default config (or atleast turn off everything in stats
thats off by default) to see this bug.
And if you guys want to be more confused then when i'll make that
conenction limit p
Tom Lane wrote:
I'm still missing what the exact "bug fix" is here.
The bug is:
- a backend starts up and sends the collector a BESTART message. For the
sake of clarity, suppose that the backend is the first and only backend
connected to its database.
- the stats collector receives the BES
Neil Conway <[EMAIL PROTECTED]> writes:
> Makes sense to me -- I'll take a look at implementing this. For now I'll
> just commit the bug fix.
I'm still missing what the exact "bug fix" is here. So far we have
established that (a) the n_backends count is not tracked by the
collector; (b) the coll
Tom Lane wrote:
Right. So do we care whether the collector has the right number?
Not at present; n_backends is not read/written by the stats collector
itself, it is just in the hash table for the convenience of backends who
read in the stats file.
Or should we push the responsibility for
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I looked at this but did not actually see the code path that requires
>> forcing creation of the per-DB entry right at this spot. The HASH_FIND
>> calls for this hashtable seem to all happen on the backend side not the
>> collector side.
Tom Lane wrote:
I looked at this but did not actually see the code path that requires
forcing creation of the per-DB entry right at this spot. The HASH_FIND
calls for this hashtable seem to all happen on the backend side not the
collector side. Can you explain why we need this?
Yeah, I missed
Neil Conway <[EMAIL PROTECTED]> writes:
> Yeah, this is a bug. Attached is a fix. I'll apply this to HEAD later
> today barring any objections.
I looked at this but did not actually see the code path that requires
forcing creation of the per-DB entry right at this spot. The HASH_FIND
calls for t
Petr Jelínek wrote:
I am bit confused now because I am no really sure if it's intended to be
this way or not - 8.0 behaviour was to report numbackends when stats
were on, now it reports numbackends when stats_row_level is true.
Yeah, this is a bug. Attached is a fix. I'll apply this to HEAD la
Alvaro Herrera wrote:
Prepared transactions can be filtered out by checking the pid struct
member. I'm not sure if anybody would object to adding the
authenticated user Id to ProcArray, but I don't see why not.
Very well, it seems to work this way (although the code for storing
userid in PG
On Sun, Jun 26, 2005 at 08:52:55PM +0200, Petr Jelínek wrote:
> Alvaro Herrera wrote:
> >Maybe you could make some checks against the shared array of PGPROCs
> >(procarray.c), for the per-database limit at least. Not sure about
> >per-user limit.
>
> Thats good idea (I could maybe add userid to P
On Sun, 26 Jun 2005, Petr Jelínek wrote:
Alvaro Herrera wrote:
Maybe you could make some checks against the shared array of PGPROCs
(procarray.c), for the per-database limit at least. Not sure about
per-user limit.
Thats good idea (I could maybe add userid to PGPROC struct too) but I think
Alvaro Herrera wrote:
I don't think this approach is very user-friendly. I'd vote for the
catalog approach, I think.
Ok I am fine with both but catalog changes would mean more hacking of
ALTER DATABASE and ALTER USER.
Maybe you could make some checks against the shared array of PGPROCs
(
On Sun, Jun 26, 2005 at 07:46:32PM +0200, Petr Jelínek wrote:
> Euler Taveira de Oliveira wrote:
>
> >IIRC, people want the last one. We have more control if we can set it
> >per user or per database.
>
> Like I said, guc variables _can_ be set per user or per database if you
> use right context
Euler Taveira de Oliveira wrote:
IIRC, people want the last one. We have more control if we can set it
per user or per database.
Like I said, guc variables _can_ be set per user or per database if you
use right context.
Talking about pgstat, I think you can rely on
it 'cause it can be disa
Hi Petr,
> One more thing, do you have more concerns about that max connection
> out
> of the fact it uses pgstat ?
> For example are guc variables ok for this or should it be new
> variable
> in pg_shadow & pg_database etc - I would like to rewrite it just once
> or
> twice not ten times.
>
I
One more thing, do you have more concerns about that max connection out
of the fact it uses pgstat ?
For example are guc variables ok for this or should it be new variable
in pg_shadow & pg_database etc - I would like to rewrite it just once or
twice not ten times.
--
Regards
Petr Jelinek (PJM
Tom Lane napsal(a):
[ shrug... ] Don't see that here; sure it isn't something broken in
your local modified version?
Well I tryed it with unmodified cvs copy and I have numbackends is 0
when 40 clients are connected (using default config)
I am bit confused now because I am no really sure
=?windows-1250?Q?Petr_Jel=EDnek?= <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What bug exactly?
>>
> Database stats aren't initialized so everything in pg_stat_database is
> always zero.
[ shrug... ] Don't see that here; sure it isn't something broken in
your local modified version?
Tom Lane wrote:
What bug exactly?
Database stats aren't initialized so everything in pg_stat_database is
always zero.
--
Regards
Petr Jelinek (PJMODOS)
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
=?windows-1250?Q?Petr_Jel=EDnek?= <[EMAIL PROTECTED]> writes:
> BTW you should still apply that pgstat.c.diff because it fixes bug in
> current CVS
What bug exactly?
regards, tom lane
---(end of broadcast)---
TIP 9: In vers
Andrew Dunstan wrote:
Is this what is intended by the TODO item? I thought that it was intended to
allow max connections to be specified on a per-db or per-user basis, not
just for global limits on per-user or per-db connections.
They are - ALTER DATABASE dbname SET max_db_conenctions = '10'
Petr Jelínek said:
>
> Something about patch:
> I added two new guc variables name max_db_connections and
> max_user_connections which can be set by superuser which means it can
> be in main config file or in user/database config.
Is this what is intended by the TODO item? I thought that it was
Ok didn't know that stats are well behind actual state - I used pgstat
because it already stores number of conenctions per database so I
thought doing same thing again is needless.
So you think I should store those data somewhere myself. What you think
is best place, some extra hash or in system
=?ISO-8859-2?Q?Petr_Jel=EDnek?= <[EMAIL PROTECTED]> writes:
> patch I attached allows to set connectin limits per user or per database
> (it's on TODO list).
I don't think this is going to work. The first problem with it is that
it changes pgstats from an optional into a required part of the sys
Hello,
patch I attached allows to set connectin limits per user or per database
(it's on TODO list).
It's proposal because I am not sure if this implementation can be
accepted (I never made new feature patch for postgres so I really dunno)
and I would like to know what you guys think about it
28 matches
Mail list logo
