On Wed, 2004-05-05 at 00:22, Christopher Kings-Lynne wrote:
> > 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 subtransac
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > 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 ar
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 va
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
s
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 transactio
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 ca
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 la
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. Naturall
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
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 [so
> ...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 manage
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
hashfloat4(PG_FUNCTIO
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
>
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." (Same as how MySQL guesses th
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."
> > (S
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."
> (Same as how MySQL guesses the result of a modulo operation, and gets it
>
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."
> > (Same as how MySQL guesses the result of a m
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 resource
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 stu
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 bo
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
> > p
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 I
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
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 i
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. T
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
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.
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
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, n
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
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.c
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
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 work
33 matches
Mail list logo
