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 'slashdot
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
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
At 11:51 PM 24/10/2002 -0400, Bruce Momjian wrote:
Your idea of using SEEK_SET is good, except I was concerned that the
checkSeek call will move the file pointer. Is that OK? It doesn't seem
appropriate.
The call is made just after the file is opened (or it should be!), so
SEEK_SET, 0 will
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
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 hasn't
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 get
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 other
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 it
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
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 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 accounting and check
to see if there is a restriction ...
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
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 accounting
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 see an
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 ...
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
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.
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
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 coordinate
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 create and
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 spike, which
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 seems
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, limit on number of
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 your
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 other
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
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
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-database, as
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, 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
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, we may get
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 !?!
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 you
34 matches
Mail list logo
