Re: [HACKERS] PostgreSQL pre-fork speedup

2004-05-04 Thread sdv mailer
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

Re: [HACKERS] inconsistent owners in newly created databases?

2004-05-04 Thread Fabien COELHO
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

Re: [HACKERS] I need Help

2004-05-04 Thread Martin Marques
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

Re: [HACKERS] inconsistent owners in newly created databases?

2004-05-04 Thread Tom Lane
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

Re: [HACKERS] Weird prepared stmt behavior

2004-05-04 Thread Alvaro Herrera
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

Re: [HACKERS] Call for 7.5 feature completion

2004-05-04 Thread Alvaro Herrera
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

Re: [HACKERS] inconsistent owners in newly created databases?

2004-05-04 Thread Fabien COELHO
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

Re: [HACKERS] Hacking postgres backend process

2004-05-04 Thread Alvaro Herrera
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

Re: [HACKERS] inconsistent owners in newly created databases?

2004-05-04 Thread Tom Lane
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

[HACKERS] The features I'm waiting for.

2004-05-04 Thread scott.marlowe
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

Re: [HACKERS] inconsistent owners in newly created databases?

2004-05-04 Thread Fabien COELHO
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

Re: [HACKERS] The features I'm waiting for.

2004-05-04 Thread David Garamond
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

Re: [HACKERS] The features I'm waiting for.

2004-05-04 Thread scott.marlowe
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

Re: [HACKERS] The features I'm waiting for.

2004-05-04 Thread Bruce Momjian
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,

Re: [HACKERS] The features I'm waiting for.

2004-05-04 Thread Mike Mascari
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

[HACKERS] Resource allocation?

2004-05-04 Thread David Fetter
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

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-05-04 Thread Bruce Momjian
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

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-05-04 Thread Robert Treat
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

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-05-04 Thread Alvaro Herrera
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

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

2004-05-04 Thread jearl
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

Re: [HACKERS] PITR logging control program

2004-05-04 Thread Simon Riggs
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

[HACKERS] More Hashing questions

2004-05-04 Thread Greg Stark
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

Re: [HACKERS] Hacking postgres backend process

2004-05-04 Thread Carl E. McMillin
...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] Multiple Xids in PGPROC?

2004-05-04 Thread Alvaro Herrera
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

Re: [HACKERS] Multiple Xids in PGPROC?

2004-05-04 Thread Tom Lane
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

Re: [HACKERS] Multiple Xids in PGPROC?

2004-05-04 Thread Bruce Momjian
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,

Re: [HACKERS] Multiple Xids in PGPROC?

2004-05-04 Thread Christopher Kings-Lynne
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

Re: [HACKERS] Multiple Xids in PGPROC?

2004-05-04 Thread Bruce Momjian
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

Re: [HACKERS] Multiple Xids in PGPROC?

2004-05-04 Thread Christopher Kings-Lynne
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

Re: [HACKERS] Multiple Xids in PGPROC?

2004-05-04 Thread Christopher Kings-Lynne
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

Re: [HACKERS] Multiple Xids in PGPROC?

2004-05-04 Thread Rod Taylor
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

Re: [HACKERS] I need Help

2004-05-04 Thread mike g
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