Re: slow mail server ? - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: slow mail server ?
Date
Msg-id 20050221113506.M75321@ganymede.hub.org
Whole thread Raw
In response to slow mail server ?  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: slow mail server ?  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
On Mon, 21 Feb 2005, Oleg Bartunov wrote:

> Marc,
>
> Below is a message I just received and I'm wondering what's a problem
> of such delay ?  5 days is too much :)

It was posted by someone not subscribed to the mailing list, and had to be 
manually approved by the moderator (me) before it would go through ...


>     Regards,
>         Oleg
> _____________________________________________________________
> Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> Sternberg Astronomical Institute, Moscow University (Russia)
> Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
> phone: +007(095)939-16-83, +007(095)939-23-83
>
> ---------- Forwarded message ----------
> Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159])
>    by ra.sai.msu.su (8.12.10/8.12.10) with ESMTP id j1L6Mo5P012614;
>    Mon, 21 Feb 2005 09:22:50 +0300 (MSK)
> Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
>    by svr4.postgresql.org (Postfix) with ESMTP id 9264A5AFD51;
>    Mon, 21 Feb 2005 06:22:48 +0000 (GMT)
> X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
> Received: from localhost (unknown [200.46.204.144])
>    by svr1.postgresql.org (Postfix) with ESMTP id 3C73D8BA156
>    for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Wed,
>    16 Feb 2005 20:35:42 +0000 (GMT)
> Received: from svr1.postgresql.org ([200.46.204.71])
> by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
> with ESMTP id 47785-08
> for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
> Wed, 16 Feb 2005 20:35:20 +0000 (GMT)
> Received: from lnfm1.sai.msu.ru (lnfm1.sai.msu.ru [195.208.220.1])
>    by svr1.postgresql.org (Postfix) with ESMTP id 126A78B9EE3
>    for <pgsql-hackers@postgresql.org>; Wed, 16 Feb 2005 20:28:51 +0000 (GMT)
> Received: from lnfm1.sai.msu.ru (localhost.localdomain [127.0.0.1])
>    by lnfm1.sai.msu.ru (8.12.8/8.12.8) with ESMTP id j1GKSjOg010158;
>    Wed, 16 Feb 2005 23:28:45 +0300
> Received: from localhost (math@localhost)
>    by lnfm1.sai.msu.ru (8.12.8/8.12.8/Submit) with ESMTP id j1GKSjaM010154;
>    Wed, 16 Feb 2005 23:28:45 +0300
> X-Authentication-Warning: lnfm1.sai.msu.ru: math owned process doing -bs
> Date: Wed, 16 Feb 2005 23:28:45 +0300 (MSK)
> From: "Sergey E. Koposov" <math@sai.msu.ru>
> To: Tom Lane <tgl@sss.pgh.pa.us>
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Strange RETURN NEXT behaviour in Postgres 8.0 
> In-Reply-To: <26214.1108580068@sss.pgh.pa.us>
> Message-ID: <Pine.LNX.4.44.0502162252060.25847-100000@lnfm1.sai.msu.ru>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> X-Virus-Scanned: by amavisd-new at hub.org
> X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=
> X-Spam-Level: X-Mailing-List: pgsql-hackers
> Precedence: bulk
> Sender: pgsql-hackers-owner@postgresql.org
>
>> "Sergey E. Koposov" <math@sai.msu.ru> writes:
>> > LOOP
>> >         FETCH cur into rec;
>> >         RETURN NEXT rec;
>> >         EXIT WHEN NOT FOUND;
>> > END LOOP;
>> > RETURN;
>> 
>> Don't you think you should have the EXIT *above* the RETURN NEXT?
>> I would expect this to emit a bogus row of nulls after the last row
>> returned by the cursor.  (At least that's what I get with current
>> sources.  Pre-8.0 it might return the last row twice.)
>
> Yes, surely EXIT should be written before RETURN NEXT, it was my error,
> (thanks, but I've found that error by myself, after posting my message) But 
> that small bug does not affect the original problem.
>
>> Running it on a 500-million-row table would quite possibly run out of
>> memory or disk space, too, because RETURN NEXT accumulates all the
>> results before the function is actually exited.
>
> Yes, that's right, but I did not waited until the whole table was loaded in
> the function. The error, which is the subject of current thread occured
> just immediately after "select * from yyy()", so surely was not caused by
> memory overfilling.
>
> Concerning to the exact form of my functions (using cursors, but still
> collecting all the data in the memory). As I understand this is the only one
> way (or just the simplest way ???) to execute fully dynamic queries returned 
> by C function in PL/SQL.
> For the real functions which I use, instead of
>
> query = ''SELECT * FROM usno'';
>
> I have
>
> query = my_C_function(some_args);
>
>            (see full code in my first message)
>
>
> ------------------------------------------------------------
> Sergey E. Koposov
> Sternberg Astronomical Institute, Moscow University (Russia)
> Max-Planck Institute for Astronomy (Germany) Internet: math@sai.msu.ru, 
> http://lnfm1.sai.msu.su/~math/
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


pgsql-hackers by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: win32 performance - fsync question
Next
From: Jeff
Date:
Subject: Re: Data loss, vacuum, transaction wrap-around