Peter Eisentraut wrote:
GUC supports per-user/per-db values.
We already had discussion here about GUC for this and we agreed that
catalog change is better than new GUC variable in this case.
--
Regards
Petr Jelinek (PJMODOS)
---(end of broadcast)--
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 1. August 2005 16:08 schrieb Bruce Momjian:
>>> Would this not work in the context of the general user-specific ALTER
>>> USER ... SET something = something?
>>
>> No because it isn't a GUC variable, it is per-user/db value.
> GUC supports
Am Montag, 1. August 2005 16:08 schrieb Bruce Momjian:
> > Would this not work in the context of the general user-specific ALTER
> > USER ... SET something = something?
>
> No because it isn't a GUC variable, it is per-user/db value.
GUC supports per-user/per-db values.
--
Peter Eisentraut
http:
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> Would this not work in the context of the general user-specific ALTER USER
>> ...
>> SET something = something?
> No because it isn't a GUC variable, it is per-user/db value. We could
> have used that syntax, but it might confuse people.
Yeah
An updated version of your patch has been applied and will be in 8.1. Thanks.
---
pgman wrote:
>
> I have "worked over" your patch and I think it is ready for application.
>
> I changed the syntax to CONNECTION LIMIT, whi
Peter Eisentraut wrote:
> Am Montag, 25. Juli 2005 18:31 schrieb Tom Lane:
> > Bruce Momjian writes:
> > > The new syntax for this command is CREATE/ALTER DATABASE/USER:
> > > | MAX CONNECTIONS Iconst
> > >
> > > This adds 'max' as a keyword, though at a fairly unreserved level, I
Am Montag, 25. Juli 2005 18:31 schrieb Tom Lane:
> Bruce Momjian writes:
> > The new syntax for this command is CREATE/ALTER DATABASE/USER:
> > | MAX CONNECTIONS Iconst
> >
> > This adds 'max' as a keyword, though at a fairly unreserved level, I
> > think. Should we use the syntax
Bruce Momjian writes:
> I have "worked over" your patch and I think it is ready for application.
I've made another pass over this and should be able to commit tomorrow
(I'm about to knock off for today, and ran out of time to test
pg_dumpall). One thing I changed was that it didn't make sense to
Here is promised documentation.
Be warned that both my writing skills and my english are far from good :)
--
Regards
Petr Jelinek (PJMODOS)
Index: doc/src/sgml/catalogs.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/catalo
Petr Jelinek wrote:
> Bruce Momjian wrote:
>
> >I removed your use of the pg_auth flat file. By the time you have the
> >PROC entry to do your lookups, you might as well just use the system
> >cache.
> >
> >There is a race condition in the code because we set our PROC entry
> >before we check for
Bruce Momjian wrote:
I removed your use of the pg_auth flat file. By the time you have the
PROC entry to do your lookups, you might as well just use the system
cache.
There is a race condition in the code because we set our PROC entry
before we check for other entries. If there is one connect
Petr Jelinek wrote:
> Bruce Momjian wrote:
>
> >The new syntax for this command is CREATE/ALTER DATABASE/USER:
> >
> >| MAX CONNECTIONS Iconst
> >
> >This adds 'max' as a keyword, though at a fairly unreserved level, I
> >think. Should we use the syntax LIMIT CONNECTIONS so we don
Bruce Momjian wrote:
The new syntax for this command is CREATE/ALTER DATABASE/USER:
| MAX CONNECTIONS Iconst
This adds 'max' as a keyword, though at a fairly unreserved level, I
think. Should we use the syntax LIMIT CONNECTIONS so we don't have to
add MAX as a keyword at all?
Bruce Momjian writes:
> The new syntax for this command is CREATE/ALTER DATABASE/USER:
> | MAX CONNECTIONS Iconst
> This adds 'max' as a keyword, though at a fairly unreserved level, I
> think. Should we use the syntax LIMIT CONNECTIONS so we don't have to
> add MAX as a keyword a
The new syntax for this command is CREATE/ALTER DATABASE/USER:
| MAX CONNECTIONS Iconst
This adds 'max' as a keyword, though at a fairly unreserved level, I
think. Should we use the syntax LIMIT CONNECTIONS so we don't have to
add MAX as a keyword at all?
--
Bruce Momjian napsal(a):
I am ready to apply this patch. Would you make the additional changes
you suggested? Is there any way to see the limits except to query
pg_authid?
Yes I will - pg_dump is already done (I attached it because it should be
aplied with orginal patch), documentation depen
> Patch includes only changes to backend, I will make pg_dump, ecpg and
> documentation patches once this is completed and accepted by team.
I am ready to apply this patch. Would you make the additional changes
you suggested? Is there any way to see the limits except to query
pg_authid?
--
Alvaro Herrera wrote:
I was wondering if there was some way to defer the user check till a
later time, when the pg_authid relation could be checked? Not sure if
that's a good idea, but it may help reduce the impact of the change, and
thus chances that it'd be rejected.
Well It can, but it wo
On Mon, Jul 04, 2005 at 01:08:05AM +0200, Petr Jelinek wrote:
> Stephen Frost wrote:
> New version which works with roles is attached (diffed against cvs),
> everything else is mostly same.
> I also had to readd roleid to flatfiles because I need it in
> InitProcess() function.
I was wondering
Stephen Frost wrote:
This should almost certainly be a pg_database_ownercheck() call instead.
Right there wasn't pg_database_ownercheck at the time I was writing it,
fixed
The rest needs to be updated for roles, but looks like it should be
pretty easy to do. Much of it just needs to be r
* Petr Jelinek ([EMAIL PROTECTED]) wrote:
> + if (!(superuser()
> + || ((Form_pg_database) GETSTRUCT(tuple))->datdba ==
> GetUserId()))
> + aclcheck_error(ACLCHECK_NOT_OWNER, ACL_KIND_DATABASE,
> +stmt->dbname);
This should almos
Alvaro Herrera wrote:
> On Sat, Jul 02, 2005 at 04:28:48PM -0400, Bruce Momjian wrote:
>
> > We will need these:
> >
> > > Patch includes only changes to backend, I will make pg_dump, ecpg and
> > > documentation patches once this is completed and accepted by team.
> >
> > Your patch has been ad
On Sat, Jul 02, 2005 at 04:28:48PM -0400, Bruce Momjian wrote:
> We will need these:
>
> > Patch includes only changes to backend, I will make pg_dump, ecpg and
> > documentation patches once this is completed and accepted by team.
>
> Your patch has been added to the PostgreSQL unapplied patche
We will need these:
> Patch includes only changes to backend, I will make pg_dump, ecpg and
> documentation patches once this is completed and accepted by team.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It wil
Hi,
I attached second try of per-database and per-user connection limit for
your review.
This time I am using information stored in ProcArray to get number of
connections - I modified PGPROC struct to also include userid.
Limits for user and database are stored in catalog tables. This apro
25 matches
Mail list logo