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
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
"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
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
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, th
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 o
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
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, ne
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
>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 bac
>>
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 funct
Koichi Suzuki wrote:
> Hi, This is Suzuki from NTT DATA Intellilink.
>
> I told Bruce Momjan that I and my colleagues are interested in
> implementing PITR in BOF in NY LW2004. NTT's laboratory is very
> interested in this issue and I'm planning to work with them. I hope we
> could cooperate.
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
c
>Bruce Momjian wrote
> 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
> >
U. Postgresql doesn't natively support cross database queries...
On Thu, 12 Feb 2004, Stef wrote:
> 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' ?
>
> Fo
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 we
> > 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 pret
> 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 'cross-sche
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
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:
>
> http://momjian.postgresql.org/cgi-bin/
[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
f
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 regre
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
>
> > > 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
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 pat
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?
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 trigge
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 er
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 D
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. Wer
"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 broadc
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.
-
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 "thuput_qs1.r
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 abilit
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
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
"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 b
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
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 PROTECT
> 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
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 printf-sty
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)
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 m
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 =
> 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 c
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 ch
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 res
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 sugg
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 psq
>> 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.
>
> I
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
51 matches
Mail list logo
