Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uh7JE-00Adbi-Ga for pgsql-general@arkaria.postgresql.org; Wed, 30 Jul 2025 13:57:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uh7JA-009yf8-Ou for pgsql-general@arkaria.postgresql.org; Wed, 30 Jul 2025 13:57:29 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uh7JA-009yf0-81 for pgsql-general@lists.postgresql.org; Wed, 30 Jul 2025 13:57:28 +0000 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uh7J8-001ZBH-1U for pgsql-general@lists.postgresql.org; Wed, 30 Jul 2025 13:57:27 +0000 Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-61568fbed16so3461886a12.3 for ; Wed, 30 Jul 2025 06:57:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1753883844; x=1754488644; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wkQ0odzdYjWzhRaIHBnl+3KQNkl9a5g5yLRGV64pLLA=; b=cDSAEKO5vZlI94XXaygQnGiqjT+ZIBwsij41e6GE8Aa8MRN0PwzMzUozwOnEv1nfOI GRiPTS2UcPZfBlIHnOH3es490cYPNntj1p6pqmqHIjuoN+IxR+X5latrO6T5Eliao83U A5Aw59nqu90bb82PL/VoPf+sG/l6OXISnE9HBpmbzf2fPc0aOYxdKi7tmsSs2ScqVNeL 3voTpqVK1IhusSxwSmIo57TPPK9gIQ3b2+FzyLm05Qpy4g46vmIrwhV4+bFyP6995FS8 7NlEegtgdhWjzSQfcflsFccY/ZsG1TYVeNZTV2X2UhVTE1jxd+omXj8dHGpl95+x6hFy 3Fnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753883844; x=1754488644; 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=wkQ0odzdYjWzhRaIHBnl+3KQNkl9a5g5yLRGV64pLLA=; b=fQNf1p1WbV4kUsh9kqUtmszBLb2Mz4jcHZQJlr0EVZxuj4mGMOcOtrzzQx5rd84JXi E9ntETozsPyvMM3nqInXQ2YeRAdmt1ex0HGlJvm0XCVGZVEs0/G2/8gWxEZUt8o1Iqys v9JmY1KwIM0pbam9Lsi+fspRtHASGAbODMJ4wj52Vbngo4liekqfIpvj3rjHf4Se7i67 z3chFohWhUXalflbodsTP7TJRhbKlGcIWbe9yuo6JiJV6b+d5wuTNQozpHkwP+ZllCNr Tg285dLbkjWJheNv71m8ug4upUuvzDX7y7OwYme2BdoQoPrGVkev/OSLpn0ZB0MSDrUO fGeA== X-Forwarded-Encrypted: i=1; AJvYcCWQo9sTJ6/sAYbXd9/3c3ONdOjBv+w2corazljxynDDeSTjQ33vfW7gfqtRM7vdT4ifRZ92gvjPF4W0yGpM@lists.postgresql.org X-Gm-Message-State: AOJu0YzsKVImkb3dh3zfWeWbeojA1phcSVtg0jThepUtyELVFzERSwvv B6aYs7zuLoXpC2eKT2qs0FEHchwzU2tMB1PyAMH3XEPCx2IE0tU7PGasqPk8thOvNBq2eZ4Fpvx 1T+NtOp89IciTYfcKYwDJyQe44ZLk2bs7HyuL41I= X-Gm-Gg: ASbGnctBtjhJkrYeFtLanJDd70ESEnCQpQGfCymOsUH+BY+qevMuKUhfWZWxgIsKQCQ sEqEOuHAky4w15F5Z19e/DgYQ/K9JIst2epba6ddO/Z2xHgrAbH9hiz6Yge7zWT+QSsyFw8JmGs /nJeAnq/6e6Ya/LVVa5jH5wQCTY6r+p6T+dm1ZXa5kNEv9t5Y90wTkJHpk07o2NscBT6EiFE2m4 A76VqDEM/2y8CPT/c4= X-Google-Smtp-Source: AGHT+IG+R3c51r/8mCG3Zrh9QGr1JdjpxU+eOv9ZDHU3wxXtNbsgWlFeBneqqLKt7Gij2lsoMmK3N0EOgOE8J3CbcyI= X-Received: by 2002:aa7:ce0a:0:b0:609:9115:60f1 with SMTP id 4fb4d7f45d1cf-615871e56b4mr3340350a12.16.1753883843268; Wed, 30 Jul 2025 06:57:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Siraj G Date: Wed, 30 Jul 2025 19:27:11 +0530 X-Gm-Features: Ac12FXz2_-rJlKNhX5a29oNJqXf21fuccfGGZJ-BKyA_ByGOeCBoAvc9IekaVgM Message-ID: Subject: Re: Failing to allocate memory when I think it shouldn't To: Christoph Moench-Tegeder Cc: Thomas Ziegler , "pgsql-general@lists.postgresql.org" Content-Type: multipart/alternative; boundary="00000000000074959a063b25e76d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000074959a063b25e76d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Christoph I am getting the same error in postgres 12 (sorry that our version upgrade sucks). I see that hash_mem_multiplier is available from version 13. What could we do in version 12? The error is: Timezones: 104120 total in 2 blocks; 2624 free (0 chunks); 101496 usedindex info: 1024 total in 1 blocks; 48 free (0 chunks); 976 used : pg _ErrorContext: 8192 total in 1 blocks; 7936 free (4 chunks); 256 used= t s_Grand total: 110141936 bytes in 2085 blocks; 2842528 free (149 chunks); 107299408 used dict_oid_index index info: 1024 total in 1 blocks; 48 free (0 chunks); 976 used: pg_event_trigger_oid_index index info: 3072 total in 2 blocks; 1216 free (3 chunks); 1856 used: pg_conversion_default_index index info: 3072 total in 2 blocks; 1136 free (2 chunks); 1936 used: pg_operator_oprname_l_r_n_index index info: 2048 total in 2 blocks; 680 free (2 chunks); 1368 used: pg_trigger_tgrelid_tgname_index index info: 2048 total in 2 blocks; 760 free (2 chunks); 1288 used: pg_enum_typid_label_index index info: 1024 total in 1 blocks; 48 free (0 chunks); 976 used: pg_ts_config_oid_index index info: 1024 total in 1 blocks; 48 free (0 chunks); 976 used: pg_user_mapping_oid_index index info: 2048 total in 2 blocks; 704 free (3 chunks); 1344 used: pg_opfamily_am_name_nsp_index index info: 1024 total in 1 blocks; 48 free (0 chunks); 976 used: pg_foreign_table_relid_index index info: 2048 total in 2 blocks; 952 free (1 chunks); 1096 used: pg_type_oid_index index info: 1024 total in 1 blocks; 48 free (0 chunks); 976 used: pg_aggregate_fnoid_index 47 more child contexts containing 80896 total in 78 blocks; 25784 free (51 chunks); 55112 used PrivateRefCount: 8192 total in 1 blocks; 2624 free (0 chunks); 5568 used MdSmgr: 8192 total in 1 blocks; 5528 free (0 chunks); 2664 used LOCALLOCK hash: 16384 total in 2 blocks; 4600 free (2 chunks); 11784 used Timezones: 104120 total in 2 blocks; 2624 free (0 chunks); 101496 used ErrorContext: 8192 total in 1 blocks; 7936 free (4 chunks); 256 used Grand total: 74714976 bytes in 1007 blocks; 2893968 free (151 chunks); 71821008 used 10.3.2.133,2025-07-30 19:03:04 IST,431246,orchids_letseduvate_db,autoscaling,1,ERROR: out of memory 10.3.2.133,2025-07-30 19:03:04 IST,431246,orchids_letseduvate_db,autoscaling,2,DETAIL: Failed on request of size 32800 in memory context "HashBatchContext". We have these memory settings: work_mem=3D2GB maintenance_work_mem=3D2GB shared_buffers=3D48GB max_parallel_workers=3D8 This issue is happening in the REPLICA instance. Regards Siraj On Wed, Sep 18, 2024 at 12:35=E2=80=AFAM Christoph Moench-Tegeder < cmt@burggraben.net> wrote: > Hi, > > ## Thomas Ziegler (thomas.ziegler@holmsecurity.com): > > > Except for pgAudit, I don't have any extensions, so it is probably the > > JIT. I had no idea there was a JIT, even it should have been obvious. > > Thanks for pointing this out! > > There is - it even has it's own chapter in the documentation: > https://www.postgresql.org/docs/current/jit.html > Most importantly, you can disable JIT per session ("SET jit=3Doff") > or globally in the configuration file (jit=3Doff, reload is > sufficient) or with any of the other usual configuration mechanisms. > If that fixes your problem, congratulations (and the problem is > somewhere down between bytecode generation and what and how llvm > (in its particular version) generates from that). > > > Is the memory the JIT takes limited by 'work_mem' or will it just take > > as much memory as it needs? > > The latter. > > Regards, > Christoph > > -- > Spare Space > > > --00000000000074959a063b25e76d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Christoph

I am getting the same e= rror in postgres 12 (sorry that our version upgrade sucks). I see that hash= _mem_multiplier is available from version 13. What could we do in version 1= 2?

The error is:
=C2=A0 =C2=A0 =C2=A0 Ti= mezones: 104120 total in 2 blocks; 2624 free (0 chunks); 101496 usedindex i= nfo: 1024 total in 1 blocks; 48 free (0 chunks); 976 used
: pg =C2=A0_Er= rorContext: 8192 total in 1 blocks; 7936 free (4 chunks); 256 usedt
s_Gr= and total: 110141936 bytes in 2085 blocks; 2842528 free (149 chunks); 10729= 9408 used
dict_oid_index
=C2=A0 =C2=A0 index info: 1024 total in 1 bl= ocks; 48 free (0 chunks); 976 used: pg_event_trigger_oid_index
=C2=A0 = =C2=A0 index info: 3072 total in 2 blocks; 1216 free (3 chunks); 1856 used:= pg_conversion_default_index
=C2=A0 =C2=A0 index info: 3072 total in 2 b= locks; 1136 free (2 chunks); 1936 used: pg_operator_oprname_l_r_n_index
= =C2=A0 =C2=A0 index info: 2048 total in 2 blocks; 680 free (2 chunks); 1368= used: pg_trigger_tgrelid_tgname_index
=C2=A0 =C2=A0 index info: 2048 to= tal in 2 blocks; 760 free (2 chunks); 1288 used: pg_enum_typid_label_index<= br>=C2=A0 =C2=A0 index info: 1024 total in 1 blocks; 48 free (0 chunks); 97= 6 used: pg_ts_config_oid_index
=C2=A0 =C2=A0 index info: 1024 total in 1= blocks; 48 free (0 chunks); 976 used: pg_user_mapping_oid_index
=C2=A0 = =C2=A0 index info: 2048 total in 2 blocks; 704 free (3 chunks); 1344 used: = pg_opfamily_am_name_nsp_index
=C2=A0 =C2=A0 index info: 1024 total in 1 = blocks; 48 free (0 chunks); 976 used: pg_foreign_table_relid_index
=C2= =A0 =C2=A0 index info: 2048 total in 2 blocks; 952 free (1 chunks); 1096 us= ed: pg_type_oid_index
=C2=A0 =C2=A0 index info: 1024 total in 1 blocks; = 48 free (0 chunks); 976 used: pg_aggregate_fnoid_index
=C2=A0 =C2=A0 47 = more child contexts containing 80896 total in 78 blocks; 25784 free (51 chu= nks); 55112 used
=C2=A0 PrivateRefCount: 8192 total in 1 blocks; 2624 fr= ee (0 chunks); 5568 used
=C2=A0 MdSmgr: 8192 total in 1 blocks; 5528 fre= e (0 chunks); 2664 used
=C2=A0 LOCALLOCK hash: 16384 total in 2 blocks; = 4600 free (2 chunks); 11784 used
=C2=A0 Timezones: 104120 total in 2 blo= cks; 2624 free (0 chunks); 101496 used
=C2=A0 ErrorContext: 8192 total i= n 1 blocks; 7936 free (4 chunks); 256 used
Grand total: 74714976 bytes i= n 1007 blocks; 2893968 free (151 chunks); 71821008 used
10.3.2.133,2025-= 07-30 19:03:04 IST,431246,orchids_letseduvate_db,autoscaling,1,ERROR: =C2= =A0out of memory
10.3.2.133,2025-07-30 19:03:04 IST,431246,orchids_letse= duvate_db,autoscaling,2,DETAIL: =C2=A0Failed on request of size 32800 in me= mory context "HashBatchContext".

We have= these memory settings:=C2=A0
work_mem=3D2GB
maintenance_work_= mem=3D2GB
shared_buffers=3D48GB
max_parallel_workers=3D= 8

This issue is happening in the REPLICA instance.=

Regards
Siraj

On Wed, Sep 18, 2024 at 12:35=E2=80=AFAM Christoph Moench-Tegeder <cmt@burggraben.net> wrote:
Hi,

## Thomas Ziegler (thomas.ziegler@holmsecurity.com):

> Except for pgAudit, I don't have any extensions, so it is probably= the
> JIT. I had no idea there was a JIT, even it should have been obvious.<= br> > Thanks for pointing this out!

There is - it even has it's own chapter in the documentation:
https://www.postgresql.org/docs/current/jit.html=
Most importantly, you can disable JIT per session ("SET jit=3Doff"= ;)
or globally in the configuration file (jit=3Doff, reload is
sufficient) or with any of the other usual configuration mechanisms.
If that fixes your problem, congratulations (and the problem is
somewhere down between bytecode generation and what and how llvm
(in its particular version) generates from that).

> Is the memory the JIT takes limited by 'work_mem' or will it j= ust take
> as much memory as it needs?

The latter.

Regards,
Christoph

--
Spare Space


--00000000000074959a063b25e76d--