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

On Mon, 21 Feb 2005, Marc G. Fournier wrote:

> 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 ...

thanks, Marc.



>
>
>>     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
>
    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