Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qKDMO-0000cZ-FU for pgsql-sql@arkaria.postgresql.org; Fri, 14 Jul 2023 07:37:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qKDMN-0004SQ-AB for pgsql-sql@arkaria.postgresql.org; Fri, 14 Jul 2023 07:37:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qKDMM-0004SG-U7 for pgsql-sql@lists.postgresql.org; Fri, 14 Jul 2023 07:37:03 +0000 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qKDMI-000KZ9-Vv for pgsql-sql@lists.postgresql.org; Fri, 14 Jul 2023 07:37:01 +0000 Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-99454855de1so3922366b.2 for ; Fri, 14 Jul 2023 00:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689320218; x=1691912218; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NTRnwaavvVB2xj5dGc00HcKbVu4E+BB5jnKyt2i/saE=; b=hpMpsdYAccI/isdOoXc/OaTWqnjajDvgeIe1ys8JlaXi7OFiRYZu0ufOx0f8/DHFfU B0W86551Pw/57pGLjySAnjNH6uHfR9/rDy3haQinr0JK2knuyEgIGLACvTyn8QHHCnGU XSTRikS1gLF7HBm11agCcPItQF/AuOip3Sd5zyvOJgf5gHY1qDG8TFnJCOTMni2VxqWU HgJRIXFsu13qweyEdEcmdQPrvNApTlloZgms38UlVeoKlgCi3aMTT8tWen0oyL+WZvSg GOhDRD1NmjT4Py4wHe1ZzHsI4Bw0D9G23yIOIhIZcWOTWQ6hafxsW1njeiGUTZ1d7yMx UZTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689320218; x=1691912218; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NTRnwaavvVB2xj5dGc00HcKbVu4E+BB5jnKyt2i/saE=; b=h4W9HbDjDKpmZsgt+tIL5Q32MKRIPVeYq3Vs4uAf8JJOxSXajjLLjspr9ijpiB5Rk7 ynCsiDvNgVCq0vc9yczzKGEgptSiqT8OegK6z6CG6OZvjz4EaHCXpRS34U66YB/xB/cr f83pTwRCdSlshmYDWgwnzC6QzbxcgvtznqWRQucgDSf5xEc3/+glzbjFlZUZU24GpjTB 82kCn2tokSS8UnouTdFjubyQyQSYHNi26q7c9102jGIgH9BiTnDkHmD3spLkoTLXvZ6X l6Ek2y0oMM+NSOzd0vraf/ETu3YIasr1VBaT0ZfSC/gzyzdUYoPFxV+UB0ldIsRQzycz 5GAg== X-Gm-Message-State: ABy/qLbNnhhBwIZ8VqAeOOZkUb55la5zn9bGsUb7MMdMBdr6D7OfODs9 hYIWgs0CleUr6Of4PyPzglQ2878cb47t0UMCUbM= X-Google-Smtp-Source: APBJJlEQwdeWJl5mLWYsL/UgwCECg9GpCCK+A66jCBX1ynvTT4ZeTXqmA4XFAkiNxJHJUO/n0vfPhVDFHwy1W1A4Cvo= X-Received: by 2002:a17:906:209:b0:98e:4c96:6e1c with SMTP id 9-20020a170906020900b0098e4c966e1cmr2994806ejd.67.1689320218162; Fri, 14 Jul 2023 00:36:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shaozhong SHI Date: Fri, 14 Jul 2023 08:36:46 +0100 Message-ID: Subject: Re: Memory allocation error To: Pavel Stehule Cc: pgsql-sql Content-Type: multipart/alternative; boundary="00000000000083f99906006d8346" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000083f99906006d8346 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 14 Jul 2023 at 08:14, Pavel Stehule wrote= : > Hi > > p=C3=A1 14. 7. 2023 v 8:38 odes=C3=ADlatel Shaozhong SHI > napsal: > >> A function is being called in a loop. Sometime, there is an error. >> >> sqlstate: XX000 >> NOTICE: message: invalid memory alloc request size 1073741824 >> >> What to do to resolve the issue? >> > > It depends what you do. Postgres doesn't allow to allocate bigger blocks > than 1GB. Maybe you create too big string or too big value of some other > type. But it can be signal of some cache bloating. > > Can you show source code? Can you use gdb, attach to Postgres, place > breakpoint to this error message, and when you get this error, send stack > trace? > > Regards > > Pavel > It a recursive query,. CREATE OR REPLACE FUNCTION public.downstream_start_end_ret3333(integer) RETURNS record LANGUAGE plpgsql AS $function$ declare ret int; arr int[]; rec last_arr_count; last int; max int; Begin drop table if exists t; create temp table t (idlist int[]); --select count(*) from t into max; WITH RECURSIVE walk_network(id, startpoint, endpoint, name1_text, startnode, endnode) AS ( SELECT id, startpoint, endpoint, name1_text, startnode, endnode FROM primarylink1 WHERE id =3D $1 UNION ALL SELECT n.id, n.startpoint, n.endpoint, n.name1_text, n.startnode, n.endnode FROM primarylink1 n, walk_network w WHERE w.endpoint=3Dn.startpoint and w.startpoint !=3D n.endpoint and w.endnode =3Dn.startnode and w.startnode !=3D n.endnode ) insert into t SELECT array_unique_stable(array_agg(id)) as idlist FROM walk_network; select idlist from t into rec.arr; select rec.arr[array_upper(rec.arr, 1)] into rec.last; ---select count(distinct name) from t into rec.count; drop table t; return rec; end; $function$ Perhaps, it gets into a endless loop. The original is here. Network Walking in PostGIS =C2=B7 Paul Ramsey (cleverelephant.ca) Network Walking in PostGIS =C2=B7 Paul Ramsey (cleverelephant.ca) Regards, David --00000000000083f99906006d8346 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, 14 Jul 2023 at 08:14, Pavel Stehule <pavel.stehule@gmail.com> wrote:
Hi

A function is be= ing called in a loop.=C2=A0 Sometime, there is an error.

sqlstate: XX000
NOTICE:=C2=A0 message: invalid memory alloc= request size 1073741824

What to do to resol= ve the issue?

It depends what = you do. Postgres doesn't allow to allocate bigger blocks than 1GB. Mayb= e you create too big string or too big value of some other type. But it can= be signal of some cache bloating.
Can you show source code? Can you use gdb= , attach to Postgres, place breakpoint to this error message, and when you = get this error, send stack trace?

Regards

Pavel

=
It a recursive query,.

CREATE OR REPLACE FUNC= TION public.downstream_start_end_ret3333(integer)
=C2=A0RETURNS r= ecord
=C2=A0LANGUAGE plpgsql
AS $function$
declare
ret int;
arr int[];
rec = last_arr_count;
last int;
max int;
Begin
drop table if exists t;
create temp table t (idlist int[]);=
--select count(*) from t into max;
WITH RECURSIVE walk= _network(id, startpoint, endpoint, name1_text, startnode, endnode) AS (
=C2=A0 SELECT id, startpoint, endpoint, name1_text, startnode, endno= de
=C2=A0 =C2=A0 FROM primarylink1
=C2=A0 =C2=A0 WHERE = id =3D $1
=C2=A0 UNION ALL
=C2=A0 SELECT n.id, n.startpoint, n.endpoint, n.name1_tex= t, n.startnode, n.endnode
=C2=A0 =C2=A0 FROM primarylink1 n, walk= _network w
=C2=A0 =C2=A0 WHERE w.endpoint=3Dn.startpoint and w.st= artpoint !=3D n.endpoint and w.endnode =3Dn.startnode and w.startnode !=3D = n.endnode
)
insert into t SELECT array_unique_stable(ar= ray_agg(id)) as idlist FROM walk_network;
select idlist from t in= to rec.arr;
select rec.arr[array_upper(rec.arr, 1)] into rec.last= ;
---select count(distinct name) from t into rec.count;
drop table t;
return rec;

end;
$function$

Perhaps, it gets into a endless loop.=


=

Regards,

David=C2=A0=C2=A0
--00000000000083f99906006d8346--