hello david,
i did some quick testing with this wonderful patch.
it seems there are some flaws in there still:
test=# explain select count(*)
test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL
SELECT DISTINCT n+1 FROM t )
test(# SELECT * FROM t WHERE n < 500
good morning,
this is wonderful news.
this is pretty much what we observed as well. the kernel has acted as
showstopper for many setups recently. this patch fixed most cases
related to kernel read ahead and so on for us.
in fact, posix_fadvise was the only way to prevent a big germany
compa
Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Couldn't we just have it pay attention to the existing
max_stack_depth?
Recursive query does not consume stack. The server enters an infinite
loop without consuming stack. Stack-depth error does not happen.
Tom Lane wrote:
Hans-Juergen Schoenig <[EMAIL PROTECTED]> writes:
Alvaro Herrera wrote:
Question for Hans-Juergen and Zoltan: have you tested 8.3 and do you
still see the need for this?
i have seen this problem two or three times within the past 2-3 years or
so. so,
Alvaro Herrera wrote:
Bruce Momjian wrote:
I think the case for it got a whole lot weaker in 8.3, with lazy
consumption of CIDs.
Agreed. Let's see if we get requests for it in >= 8.3 releases.
In the original submission message you find this text:
: attached is our patch aga
On Mar 23, 2008, at 9:25 PM, Volkan YAZICI wrote:
Hi,
On Sun, 23 Mar 2008, Martin Pihlak <[EMAIL PROTECTED]> writes:
Attached is a patch that enables tracking function calls through
the stats subsystem. Original discussion:
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00377.php
Int
I'm sorry to hear about this problem.
No worries - nothing lost ...
Not sure we need a LOG message to warn people about the possible
length
of recovery time. The chances of a recovery taking that much time seem
very low for normal Postgres, even with checkpoint parameters set at
their ma
On Feb 11, 2008, at 10:26 AM, Heikki Linnakangas wrote:
Hans-Juergen Schoenig wrote:
Last week we have seen a problem with some horribly configured
machine.
The disk filled up (bad FSM ;) ) and once this happened the
sysadmi killed the system (-9).
After two days PostgreSQL has still not
Last week we have seen a problem with some horribly configured machine.The disk filled up (bad FSM ;) ) and once this happened the sysadmi killed the system (-9).After two days PostgreSQL has still not started up and they tried to restart it again and again making sure that the consistency check w
good morning everybody,this is a working version of evgen potemkin's patch implementing CONNECT BY. it has been ported to 8.3 and it seems to work flawlessly with CVS head.it is not supposed to be included into 8.4 but i guess it might be useful for some people.there are still some limitations and
On the other hand I don't see why you are arguing in favor of a useless
feature whose coding is dubious; you can have _the same thing_ with nice
code and no discussion.
Because of [1] and because Mr. Schoenig's arguments
about changing schemas.
first of all; hans is enough - skip the mr
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed and
an agreement must be reached before introducing such a change (and not
during fea
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed and
an agreement must be
Remember that we were talking about supporting views, not tables. And
if a view uses a slow query then you are in immediate danger of having a
slow COPY. This may not be a problem but it needs to be discussed and
an agreement must be reached before introducing such a change (and not
during fea
apply this.
Would you redo this against current CVS? Thanks.
---
Hans-Juergen Schoenig wrote:
Folks,
We have implemented SELECT FOR UPDATE NOWAIT for PostgreSQL.
The patch attached to this email contains all the req
Geschwinde & Hans-Juergen Schoenig
--
Cybertec Geschwinde u Schoenig GmbH.
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/660/816 40 77
www.cybertec.at, www.postgresql.at
diff -r -c postgresql-8.0.0rc2.orig/doc/src/sgml/ref/select.sgml postgresql-8.0.0rc2/doc/src/sgml/ref/select.
16 matches
Mail list logo
