We used to run persistent connection until the DB
servers got maxed out because of too many idle
connections sucking up all the memory. Web servers run
different loads than database servers and persistent
connections are notorious for crashing your DB.
Connection pooling (eg. SQLRelay) didn't
Dear Tom,
However, I feel that the owner should own the public schema and maybe
some other stuff to be carefully selected, without bluring that important
distinction?
From a definitional standpoint I don't have a problem with that.
Good.
From an implementation standpoint, I fear it
El Mar 04 May 2004 01:50, Christopher Kings-Lynne escribió:
I installed postgresql 7.4 in my computer, I'm using
redhat 9.0 .
I installed pgadmin III but I can't to conecct to the
server.
The port 5432 is not open.
You need to set tcpip_socket = true in your postgresql.conf.
And in
Fabien COELHO [EMAIL PROTECTED] writes:
Another heavier but more general approach would be to add a boolean to
pg_database to tell whether the first connection housekeeping was
performed,
I was envisioning a bool column added to pg_database, and having the set
of operations just hard-coded
On Tue, May 04, 2004 at 12:03:16AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Right. But note that Tom wants to distinguish between statements
created via PREPARE (which would rollback) from those created via a
Prepare message (which wouldn't).
Actually, no, I'd
On Sat, May 01, 2004 at 09:03:03AM +0200, Hans-Jürgen Schönig wrote:
If a feature freeze is made on August 1st or even later it would be ok
because nobody is doing major database changes in summer anyway.
You seem to forget that half of the world is not in summer on August
1st. I admit that
Dear Tom,
Another heavier but more general approach would be to add a boolean to
pg_database to tell whether the first connection housekeeping was
performed,
I was envisioning a bool column added to pg_database,
and having the set of operations just hard-coded into the backend.
Why
On Wed, Apr 28, 2004 at 08:26:09AM -0700, Carl E. McMillin wrote:
I posted this subject on General discussion-list but got no takers. I'll
restate my query and be as brief as I possible.
What are the issues/dangers involved in putting an external
process-execution call in instance of main
Fabien COELHO [EMAIL PROTECTED] writes:
I was thinking about something fuzzy enough as:
UPDATE pg_catalog.pg_namespace
SET nspowner=datdba, nspacl=NULL -- NULL means default rights...
The later is simple and makes sense anyway for a newly created database.
No, I don't think it does. The
For me, the only features I'm likely to use in the upcoming releases are
nested transactions. While PITR is a great selling point, and the Windows
Port is something I do look forward to, having to do half my job
programming windows boxes, nested transactions are a feature I can
genuinely use
Dear Tom,
UPDATE pg_catalog.pg_namespace
SET nspowner=datdba, nspacl=NULL -- NULL means default rights...
The later is simple and makes sense anyway for a newly created database.
No, I don't think it does. The DBA presently can set up a site-wide
policy about use of public by altering
scott.marlowe wrote:
For me, the only features I'm likely to use in the upcoming releases are
nested transactions. While PITR is a great selling point, and the Windows
Port is something I do look forward to, having to do half my job
programming windows boxes, nested transactions are a feature
On Tue, 4 May 2004, David Garamond wrote:
scott.marlowe wrote:
For me, the only features I'm likely to use in the upcoming releases are
nested transactions. While PITR is a great selling point, and the Windows
Port is something I do look forward to, having to do half my job
David Garamond wrote:
scott.marlowe wrote:
For me, the only features I'm likely to use in the upcoming releases are
nested transactions. While PITR is a great selling point, and the Windows
Port is something I do look forward to, having to do half my job
programming windows boxes,
David Garamond wrote:
scott.marlowe wrote:
I'm sure everybody has their own favorite feature. But I can say quite
confidently that the upcoming release contains the most number of highly
anticipated features ever. Nested transaction, 2-phase commit, Windows
port... I mean these are all major
Kind people,
I'm not sure where in the docs to start looking for this, but here's
the situation:
I'd like to be able to run large batch-process jobs for caching, but
limit the total resource utilization on them, something like nice(1).
Better still would be some way to put a max on total
Robert Treat wrote:
On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote:
You know, that's kind of the point of all things related to MySQL.
It's better than nothing. PostgreSQL doesn't do things because it's
better than nothing. snip
(Same as how MySQL guesses the result of a modulo
On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote:
You know, that's kind of the point of all things related to MySQL.
It's better than nothing. PostgreSQL doesn't do things because it's
better than nothing. snip
(Same as how MySQL guesses the result of a modulo operation, and gets it
On Tue, May 04, 2004 at 03:06:53PM -0400, Robert Treat wrote:
On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote:
You know, that's kind of the point of all things related to MySQL.
It's better than nothing. PostgreSQL doesn't do things because it's
better than nothing. snip
(Same as
Robert Treat [EMAIL PROTECTED] writes:
On Tuesday 27 April 2004 15:12, Alvaro Herrera wrote:
You know, that's kind of the point of all things related to MySQL.
It's better than nothing. PostgreSQL doesn't do things because
it's better than nothing. snip (Same as how MySQL guesses the
On Fri, 2004-04-30 at 04:02, Bruce Momjian wrote:
Simon Riggs wrote:
Agreed we want to allow the superuser control over writing of the
archive logs. The question is how do they get access to that. Is it by
running a client program continuously or calling an interface script
from the
Regarding inter-data-type hash joins, would it make sense to make float
datatypes to hash to the same value as integral data types for integral
values?
Conveniently this would cover the existing special case of -0 and +0 hashing
to the same value. Something like this?
Datum
...Basically if you are in constant fear you are in the
right shift of mind to do it ... check every return code,
make sure you don't write unassigned memory, make sure the
function wears its mithril shirt at all times, etc.
Hehe! Thanks for the warning. Do you know of anyone that's managed
Hackers,
I've whacked the subtrans patch enough so that the simple tests (i.e.
non concurrent) for tuple visibility work. I can create a table and
populate it in subtransactions, rollback or commit them selectively and
get the desired effect at the end. Naturally, catalog entries also
behave
Alvaro Herrera [EMAIL PROTECTED] writes:
So, the big question is, how do we do this? The most obvious way (to
me) is to keep the whole array inside the PGPROC struct.
...
The main downside is that it potentially
requires a lot of shared memory. Can we afford that?
No. Shared memory is
Alvaro Herrera wrote:
Hackers,
I've whacked the subtrans patch enough so that the simple tests (i.e.
non concurrent) for tuple visibility work. I can create a table and
populate it in subtransactions, rollback or commit them selectively and
get the desired effect at the end. Naturally,
I remember going through this. Other backends will use pg_subtrans to
know what transactions are in progress. They have to do the standard
lookups to find the status of the parent transaction. The backend-local
list of xids is needed so the commit can clean up those subtransaction
xids so that
Christopher Kings-Lynne wrote:
I remember going through this. Other backends will use pg_subtrans to
know what transactions are in progress. They have to do the standard
lookups to find the status of the parent transaction. The backend-local
list of xids is needed so the commit can clean
I hope not, because for many of us there will be as many (if not more)
subtransactions than standard transactions.
How can that possibly be true? Every statement executed in postgres is
a transaction how many subtransactions are really needed and how can
they be as common as normal
Yup.. And some of us intend on wrapping every single statement in a
subtransaction so we can rollback on an error without aborting the main
transaction.
Point there being main transaction. What i'm saying is that the vast
majority of your transactions will be single statements. eg. single
On Wed, 2004-05-05 at 00:45, Christopher Kings-Lynne wrote:
Yup.. And some of us intend on wrapping every single statement in a
subtransaction so we can rollback on an error without aborting the main
transaction.
Point there being main transaction. What i'm saying is that the vast
Yes it is possible for both to be on the same pc. Please send mail to
the general or novice list if you need more help.
On Mon, 2004-05-03 at 11:05, olivia jurado wrote:
Hi.
I'm from Panama.
I don't speak english very well but I'm learning
english.
I Need help.
I installed
32 matches
Mail list logo