On Saturday 26 October 2002 01:04 am, Bruce Momjian wrote:
> Robert Treat wrote:
> > > Nice idea. You can now have per-user/db settings that are SET when the
> > > connection is made. You can set any GUC variable that way. We just
> > > need a variable that can look at all sessions and determine
On Sat, Oct 26, 2002 at 01:04:55 -0400,
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> The per db/user stuff is stored in the pg_database/pg_shadow tables per
> row, so they exist in permanent storage.
I have a question about this. This stuff is per user OR per db right?
When I see per db/user I
Robert Treat wrote:
> > Nice idea. You can now have per-user/db settings that are SET when the
> > connection is made. You can set any GUC variable that way. We just
> > need a variable that can look at all sessions and determine if that user
> > has exceeded their connection quota.
>
> I under
On Friday 25 October 2002 07:03 pm, Bruce Momjian wrote:
> Tom Lane wrote:
> > Robert Treat <[EMAIL PROTECTED]> writes:
> > > On Fri, 2002-10-25 at 16:17, Tom Lane wrote:
> > >> I prefer GUC variables to table entries for setting stuff like
> > >> recursion limits; they're much lighter-weight to cr
Thomas Lockhart wrote:
> >>Seems like someone ought to issue a call for port reports. The
> >>"supported platforms" list hasn't been touched ...
> > Good point. Thomas, can you take that on?
>
> No, at least not now. I'm not able to communicate reliably with the
> mailing lists, and so can not
Thomas Lockhart wrote:
> >>Seems like someone ought to issue a call for port reports. The
> >>"supported platforms" list hasn't been touched ...
> > Good point. Thomas, can you take that on?
>
> No, at least not now. I'm not able to communicate reliably with the
> mailing lists, and so can not
Thomas Lockhart wrote:
> ... and just out of curiosity, why does Bruce's message have a [HACKERS]
> tag in the subject line but my reply does not? It seems to be going
> through the same mailer but with different results...
Yes, I have noticed this happening at random times.
--
Bruce Momjian
... and just out of curiosity, why does Bruce's message have a [HACKERS]
tag in the subject line but my reply does not? It seems to be going
through the same mailer but with different results...
- Thomas
---(end of broadcast)--
Seems like someone ought to issue a call for port reports. The
"supported platforms" list hasn't been touched ...
Good point. Thomas, can you take that on?
No, at least not now. I'm not able to communicate reliably with the
mailing lists, and so can not coordinate anything :( Not sure when or
Create table arnold (
a int8,
b timestamp default 'epoch'::timestamp,
c timestamp default "timestamp"('epoch'::text)
);
I think that the best way forward for us (short of re-writing the backend to
use NULL) will be to just alter the default value to the one in column b in
the test table above.
We have just upgraded from 7.1.3 to 7.2.3 over the weekend, and have just
noticed something weird with regards 'epoch'::timestamp.
In 7.1.3, 'epoch'::timestamp always returned the value 1970-01-01
00:00:00+00,...
I would expect 'epoch'::timestamp to always act as though the value were
the same a
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We are putting out beta3 today or tomorrow. It seems we are ready to
> > start considering an RC1 date, perhaps next Friday, November 1?
>
> Seems like someone ought to issue a call for port reports. The
> "supported platforms" list
Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > On Fri, 2002-10-25 at 16:17, Tom Lane wrote:
> >> I prefer GUC variables to table entries for setting stuff like recursion
> >> limits; they're much lighter-weight to create and access, and you don't
> >> need an initdb to add or remove
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We are putting out beta3 today or tomorrow. It seems we are ready to
> start considering an RC1 date, perhaps next Friday, November 1?
Seems like someone ought to issue a call for port reports. The
"supported platforms" list hasn't been touched ...
Robert Treat <[EMAIL PROTECTED]> writes:
> On Fri, 2002-10-25 at 16:17, Tom Lane wrote:
>> I prefer GUC variables to table entries for setting stuff like recursion
>> limits; they're much lighter-weight to create and access, and you don't
>> need an initdb to add or remove a parameter.
> I don't s
On Fri, 2002-10-25 at 16:17, Tom Lane wrote:
> Mike Mascari <[EMAIL PROTECTED]> writes:
> > [ extensive proposal for PROFILEs ]
> > It seems like a nice project, particularly since it wouldn't
> > affect anyone that doesn't want to use it.
>
> ... except in the added overhead to do the resource a
We are putting out beta3 today or tomorrow. It seems we are ready to
start considering an RC1 date, perhaps next Friday, November 1?
---
P O S T G R E S Q L
7 . 3 O
Mike Mascari <[EMAIL PROTECTED]> writes:
> [ extensive proposal for PROFILEs ]
> It seems like a nice project, particularly since it wouldn't
> affect anyone that doesn't want to use it.
... except in the added overhead to do the resource accounting and check
to see if there is a restriction ...
I need others wanting this before I can add something of this
sophistication to TODO.
---
Mike Mascari wrote:
> Bruce Momjian wrote:
> > Andrew Sullivan wrote:
> >
> >>On Fri, Oct 25, 2002 at 11:02:48AM -0400, Tom Lane wrot
Bruce Momjian wrote:
Andrew Sullivan wrote:
On Fri, Oct 25, 2002 at 11:02:48AM -0400, Tom Lane wrote:
So? If it hits the installation-wide limit, you'll have the same
problem; and at that point the (presumably runaway) app would have
sucked up all the connections, denying service to other app
On Fri, 2002-10-25 at 10:31, Bruce Momjian wrote:
>
> Yes, my comments related to useing db/user limits to control the number
> of persistent connections. From an ISP perspective, I can see value in
> user/db limits.
>
Yes, this would be amazingly useful. I work for a web hosting provider
and i
Andrew Sullivan wrote:
> On Fri, Oct 25, 2002 at 11:02:48AM -0400, Tom Lane wrote:
> > So? If it hits the installation-wide limit, you'll have the same
> > problem; and at that point the (presumably runaway) app would have
> > sucked up all the connections, denying service to other apps using othe
On Fri, Oct 25, 2002 at 11:02:48AM -0400, Tom Lane wrote:
> So? If it hits the installation-wide limit, you'll have the same
> problem; and at that point the (presumably runaway) app would have
> sucked up all the connections, denying service to other apps using other
> databases. I think Marc's
On Fri, 25 Oct 2002, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Basically, total connections is to be set larger than you think you will
> > > ever need, while you expect per-db to be hit, and if something keeps
> > > trying to connect and failing, w
On Fri, 25 Oct 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Basically, total connections is to be set larger than you think you will
> > ever need, while you expect per-db to be hit, and if something keeps
> > trying to connect and failing, we may get very bad connection
>
Yes, my comments related to useing db/user limits to control the number
of persistent connections. From an ISP perspective, I can see value in
user/db limits.
---
Marc G. Fournier wrote:
> On Fri, 25 Oct 2002, Bruce Momjian
On Fri, 25 Oct 2002, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > >> Well, there are two different things here. I agree that if an app
> > >> is going to use persistent connections, it should be the app's
> > >> responsibility to manage them. But a per
On Fri, 25 Oct 2002, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Well, there are two different things here. I agree that if an app
> >> is going to use persistent connections, it should be the app's
> >> responsibility to manage them. But a per-database, as opposed to
> >> i
Tom Lane <[EMAIL PROTECTED]> wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Basically, total connections is to be set larger than you think you will
> > ever need, while you expect per-db to be hit, and if something keeps
> > trying to connect and failing, we may get very bad connection
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Basically, total connections is to be set larger than you think you will
> > ever need, while you expect per-db to be hit, and if something keeps
> > trying to connect and failing, we may get very bad connection
> > performance for oth
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Basically, total connections is to be set larger than you think you will
> ever need, while you expect per-db to be hit, and if something keeps
> trying to connect and failing, we may get very bad connection
> performance for other backends.
Hmm, I see y
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Well, there are two different things here. I agree that if an app
> >> is going to use persistent connections, it should be the app's
> >> responsibility to manage them. But a per-database, as opposed to
> >> installation-wide, limi
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Well, there are two different things here. I agree that if an app
>> is going to use persistent connections, it should be the app's
>> responsibility to manage them. But a per-database, as opposed to
>> installation-wide, limit on number of connections
Tom Lane wrote:
> Greg Copeland <[EMAIL PROTECTED]> writes:
> > On Fri, 2002-10-25 at 00:52, Marc G. Fournier wrote:
> >> Ya, I've thought that one through ... I think what I'm more looking at is
> >> some way of 'limiting' persistent connections, where a server opens n
> >> connections during a sp
Greg Copeland <[EMAIL PROTECTED]> writes:
> On Fri, 2002-10-25 at 00:52, Marc G. Fournier wrote:
>> Ya, I've thought that one through ... I think what I'm more looking at is
>> some way of 'limiting' persistent connections, where a server opens n
>> connections during a spike, which then sit idle i
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Is there any way of the 'master process' *safely/accurately* knowing,
> through the shared memory link, the # of connections currently open to a
> particular database? So that a limit could be set on a per db basis, say
> as an additional arg to pg_
On Fri, 2002-10-25 at 00:52, Marc G. Fournier wrote:
> Ya, I've thought that one through ... I think what I'm more looking at is
> some way of 'limiting' persistent connections, where a server opens n
> connections during a spike, which then sit idle indefinitely since it was
> one fo those 'slashd
On Fri, 25 Oct 2002, Igor Georgiev wrote:
>
> > Next your going to ask what will stop root from stopping your
> > PostgreSQL, compiling a second copy with authentication disabled and
> > using your data directory as it's source :)
>
> He he somebody can blow up ur home with C4, but this don't stop
> Next your going to ask what will stop root from stopping your
> PostgreSQL, compiling a second copy with authentication disabled and
> using your data directory as it's source :)
He he somebody can blow up ur home with C4, but this don't stop you from
locking ur door !?!
-
39 matches
Mail list logo
