Re: slow mail server ?

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(at)sai(dot)msu(dot)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(dot)org(at)localhost(dot)postgresql(dot)org
>> Received: from localhost (unknown [200.46.204.144])
>> by svr1.postgresql.org (Postfix) with ESMTP id 3C73D8BA156
>> for <pgsql-hackers-postgresql(dot)org(at)localhost(dot)postgresql(dot)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(dot)org(at)localhost(dot)postgresql(dot)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(at)postgresql(dot)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(at)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(at)sai(dot)msu(dot)ru>
>> To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>> Cc: pgsql-hackers(at)postgresql(dot)org
>> Subject: Re: [HACKERS] Strange RETURN NEXT behaviour in Postgres 8.0
>> In-Reply-To: <26214(dot)1108580068(at)sss(dot)pgh(dot)pa(dot)us>
>> Message-ID: <Pine(dot)LNX(dot)4(dot)44(dot)0502162252060(dot)25847-100000(at)lnfm1(dot)sai(dot)msu(dot)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(at)postgresql(dot)org
>>
>>> "Sergey E. Koposov" <math(at)sai(dot)msu(dot)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(at)sai(dot)msu(dot)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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83