I will submit a patch. As soon as I have read the developers FAQ and learned
how this is done :-)
B.T.W. I needed one additional function. Do you think I should submit it
too? This function copies some behavior found in the SPI_cursor_open. If
submitted, I'd suggest that the SPI_cursor_open calls
Improving on not ideal would be good, and would get even closer to
full Oracle/SQLServer migration/compatibility. However, since I've never
looked at that section of code, I couldn't comment on any particular
approach nor implement such a change, so I'll shut up and be patient.
Imagine
On Thu, Feb 12, 2004 at 09:55:36AM +0100, Zeugswetter Andreas SB SD wrote:
Yeah, but in other db's this is solved by the frontend. e.g. in Informix
dbaccess has a mode that simply stops execution upon first error. So I don't
think this is a nogo argument, if we added such a feature to psql.
Thomas Hallgren wrote:
I will submit a patch. As soon as I have read the developers FAQ and learned
how this is done :-)
B.T.W. I needed one additional function. Do you think I should submit it
too? This function copies some behavior found in the SPI_cursor_open. If
submitted, I'd suggest
On Wed, 11 Feb 2004 [EMAIL PROTECTED] wrote:
Thank you very much for your reply.
Yes, that's true. But it seems not a good idea if I have many databases
and I want them totally seperated with each other.
What's your opinion? Thanks.
OK, here's the issue. Postgresql uses certain
Zeugswetter Andreas SB SD wrote:
Improving on not ideal would be good, and would get even closer to
full Oracle/SQLServer migration/compatibility. However, since I've never
looked at that section of code, I couldn't comment on any particular
approach nor implement such a change, so I'll
But for seperating out applications from each other, there's really
nothing to be gained by putting each seperate database application into
it's own cluster.
I believe the initial email requested individual logs, and presumably
the ability to grant superuser access without risking a user
Tom Lane wrote:
I just saw the parallel regression tests hang up again. Inspection
revealed that StrategyInvalidateBuffer() was stuck in an infinite loop
because the freelist was circular.
(gdb) p StrategyControl-listFreeBuffers
$5 = 579
(gdb) p BufferDescriptors[579]
$6 = {bufNext = 106, data =
On Wed, Feb 11, 2004 at 17:48:51 -0500,
[EMAIL PROTECTED] wrote:
Thank you very much for your reply. I'd like to discuss the why.
I don't think letting them share data and logs could gain me something.
And if I have 2 databases totally not relevant, I think the most natural
way is to make
Tom Lane [EMAIL PROTECTED] writes:
Hmmm ... maybe query_work_mem and maintenance_work_mem, or something
similar?
I'll go with these unless someone has another proposal ...
dml_sort_mem and ddl_sort_mem ?
--
greg
---(end of broadcast)---
Rod Taylor wrote:
Last time I looked,
you couldn't get the database name in the log files to allow for
mechanical filtering
Watch this space.When my log_disconnections patch makes it through the
filter process it will be followed up with a patch that allows tagging
of log lines with a
Oh, okay. So when's that fix going to be committed?
Never mind, I see you just did ...
regards, tom lane
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Hello,
Depending on your needs and transaction load per database you can easily
run 30 databases on a machine with 2 Gig of RAM. You will of course have
to use initdb for each cluster and change the tcp port for each cluster
but it works just fine.
Sincerely,
Joshua D. Drake
[EMAIL
Jan Wieck [EMAIL PROTECTED] writes:
Tom Lane wrote:
I just saw the parallel regression tests hang up again.
Anyhow, according to our discussion in early January I have changed the
code in StrategyInvalidateBuffer() so that it clears out the buffer tag
and the CDB's buffer tag. Also it will
Jeroen T. Vermeulen [EMAIL PROTECTED] writes:
It does require that the application be meticulous in its checking though.
Existing client programs, for instance, may ignore any errors coming back
from PQexec() during the transaction and just see if the COMMIT succeeds.
Such could would break in
Curt Sampson wrote:
I notice that pg_dump is still dumping CHECK constraints with the table,
rather than at the very end, as it does with all the other constraints.
As discussed in bug report #787, at
http://archives.postgresql.org/pgsql-bugs/2002-09/msg00278.php
this breaks your
Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Hmmm ... maybe query_work_mem and maintenance_work_mem, or something
similar?
I'll go with these unless someone has another proposal ...
dml_sort_mem and ddl_sort_mem ?
I thought about that, but didn't think DML/DDL was
On Thu, 12 Feb 2004, Rod Taylor wrote:
But for seperating out applications from each other, there's really
nothing to be gained by putting each seperate database application into
it's own cluster.
I believe the initial email requested individual logs, and presumably
the ability to
Ok, I have EXPLAIN ANALYZE results for both the power and throughput
tests:
http://developer.osdl.org/markw/dbt3-pgsql/
It's run #60 and the links are towards the bottom of the page under the
Run log data heading. The results from the power test is
power_query.result and
Looks good to me but I will get some other eyse on it before I apply it.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
scott.marlowe [EMAIL PROTECTED] writes:
On 12 Feb 2004, Greg Stark wrote:
dml_sort_mem and ddl_sort_mem ?
I like those. Are they an accurte representation of what's going on?
No, not particularly ...
regards, tom lane
---(end of
On 12 Feb, Josh Berkus wrote:
Mark,
It's run #60 and the links are towards the bottom of the page under the
Run log data heading. The results from the power test is
power_query.result and thuput_qs1.result, etc. for each stream in
the throughput test.
I'm confused. Were you able to get
Mark,
Oh sorry, I completely forgot that Q19 the whole purpose of this. So
#60 doesn't have the right Q19. I'll run with the one you want now.
Thanks! And the original, not the fixed, Q19 if you please. It's the
original that wouldn't finish on Postgres 7.3.
--
-Josh Berkus
Aglio
Greg Stark wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Imagine this:
BEGIN WORK;
LOCK oldtab;
CREATE_X TABLE newtab AS SELECT * FROM oldtab;
DELETE oldtab;
COMMIT
In this case, you would want the database to abort on a syntax error, right?
Hey there everyone.
Sorry for what seems to be a rather strange
thought but, could we change the seperator used to
distinguish 'cross-database' vs 'cross-schema' ?
For example, i would expect the following
to work:
CREATE OR REPLACE FUNCTION test_autohist() RETURNS
Bruce Momjian [EMAIL PROTECTED] writes:
Looks good to me but I will get some other eyse on it before I apply it.
It's in already ...
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
Michael Meskes wrote:
Just wanted to let you know that if we would be interested in adding
that patch to our main cvs the guy who wrote it would be more than
willing to change his license to BSD.
I was under the impression we wanted to implement the ANSI way to do
this. Is this what the patch
BEGIN WORK;
LOCK oldtab;
CREATE_X TABLE newtab AS SELECT * FROM oldtab;
DELETE oldtab;
COMMIT
In this case, you would want the database to abort on a syntax error, right?
Certainly not if I was typing this from the command line. Imagine the
frustration if the
Already applied. Thanks.
---
Gavin Sherry wrote:
The attached patch changes the existing behaviour of length(char(n)).
Currently, this is what happens:
template1=# select length('blah'::char(10));
length
Gavin Sherry wrote:
I believe Tom applied this while you were away.
Oh, sorry, I see it now:
test= select length('blah'::char(10));
length
4
(1 row)
I did test this before placing it the queue, but I now realize I have
been testing
[EMAIL PROTECTED] writes:
Ok, I have EXPLAIN ANALYZE results for both the power and throughput
tests:
http://developer.osdl.org/markw/dbt3-pgsql/
Thanks. I just looked at Q9 and Q21, since those are the slowest
queries according to your chart. (Are all the queries weighted the same
for
I believe Tom applied this while you were away.
Gavin
On Thu, 12 Feb 2004, Bruce Momjian wrote:
Looks good to me but I will get some other eyse on it before I apply it.
Your patch has been added to the PostgreSQL unapplied patches list at:
On Thu, 12 Feb 2004, Stef wrote:
U. Postgresql doesn't natively support cross database queries...
I know, but it does schema's, and currently, the same
notation is used to specify schema's as 'cross database'.
So the planner often reports 'cross-database not allowed'
in areas
U. Postgresql doesn't natively support cross database queries...
I know, but it does schema's, and currently, the same
notation is used to specify schema's as 'cross database'.
So the planner often reports 'cross-database not allowed'
in areas where it should at least report
case in point, the example trigger. i would have expected
deliberate schemaname.table during an insert to work, but
instead the parser complains about cross-database.
I would think just changing the error message to no schema by the name of
suchandsuch found would make it pretty clear.
In this case, you would want the database to abort on a syntax error, right?
Am I completely off thread to ask why HOW we allow an abort on syntax
errors? (at least in regard to stored functions)
Shouldn't PostgreSQL do somethng intellignet like *notice* the syntax
error in the stored function
Bruce Momjian
Simon Riggs wrote:
Tom Lane
Simon Riggs [EMAIL PROTECTED] writes:
Most importantly, other references I have state that: the ANSI
SQL-99
specification does require that if a statement errors then only
that
statement's changes are rolled back.
...if anybody
Bruce Momjian [EMAIL PROTECTED] writes:
Rod Taylor wrote:
Can this be done entirely on the client side?
Have psql silently wrap every statement going out with a BEGIN and a
COMMIT or ROLLBACK depending on whether there was an error or not?
Yep, we could do it in the client like we do for
Stef [EMAIL PROTECTED] writes:
For example, i would expect the following
to work:
CREATE OR REPLACE FUNCTION test_autohist() RETURNS trigger
AS 'BEGIN
INSERT INTO history.test2 VALUES
(new.field1,history.test_hist.nextval(), new.field2, new.field3,
On Thu, 12 Feb 2004, Stef wrote:
case in point, the example trigger. i would have expected
deliberate schemaname.table during an insert to work, but
instead the parser complains about cross-database.
I would think just changing the error message to no schema by the name of
On 12 Feb, Josh Berkus wrote:
Mark,
Oh sorry, I completely forgot that Q19 the whole purpose of this. So
#60 doesn't have the right Q19. I'll run with the one you want now.
Thanks! And the original, not the fixed, Q19 if you please. It's the
original that wouldn't finish on Postgres
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Rod Taylor wrote:
Can this be done entirely on the client side?
Have psql silently wrap every statement going out with a BEGIN and a
COMMIT or ROLLBACK depending on whether there was an error or not?
Yep, we could do it in the
scott.marlowe [EMAIL PROTECTED] writes:
Hmmm. I would think the first step would be to simply change the cross-db
queries aren't supported to one of schema either does not exist or is not
in the search path.
AFAICT the issue is that Stef thought it was complaining about a
different name
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Bruce Momjian) would write:
I guess my question is that now that we have the new cache
replacement policy, is the vacuum delay worth while. I looked at
http://developer.postgresql.org/~wieck/vacuum_cost/ and does seem
useful.
They
Andrew Dunstan wrote:
Based on Larry's idea, I had in mind to provide a third escape in the
log_line_info string (in addition to the %U and %D that I had previously
done) of %S for sessionid, which would look something like this:
402251fc.713f
I will start redoing this feature when the
Bruce Momjian wrote:
Jan Wieck wrote:
Attached is a corrected version that solves the query cancel problem by
not napping any more and going full speed as soon as any signal is
pending. If nobody objects, I'm going to commit this tomorrow.
Jan, three questions. First, is this useful now that
Jan Wieck wrote:
Attached is a corrected version that solves the query cancel problem by
not napping any more and going full speed as soon as any signal is
pending. If nobody objects, I'm going to commit this tomorrow.
Jan, three questions. First, is this useful now that we have the new
Jan Wieck wrote:
Bruce Momjian wrote:
Jan Wieck wrote:
Attached is a corrected version that solves the query cancel problem by
not napping any more and going full speed as soon as any signal is
pending. If nobody objects, I'm going to commit this tomorrow.
Jan, three questions.
48 matches
Mail list logo
