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 1rLnv4-000XaJ-Ew for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jan 2024 17:23:42 +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 1rLnv3-0024RY-Bu for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jan 2024 17:23:41 +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 1rLnv3-0024RQ-2r for pgsql-hackers@lists.postgresql.org; Fri, 05 Jan 2024 17:23:41 +0000 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rLnv0-0002W4-OZ for pgsql-hackers@lists.postgresql.org; Fri, 05 Jan 2024 17:23:39 +0000 Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a26f73732c5so193516466b.3 for ; Fri, 05 Jan 2024 09:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704475417; x=1705080217; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4HRD1m75rmyzSkd8n86RMikU1s+/iGWMK24uEirNsM0=; b=XlehoGVzf/lrBseI+UXxfWQLgEypSU/xEJclplTAfhulJiRMrvThPkqVGoueaH3gk5 1Ke2B0TTFmRDk3XMXNPoYC90W5XVU4WLOf+tvbe8B9kuPiSY+08FuiU9JI9UCe3mNzvJ XraaEXGmFQFWMct637uTA8U1Hk8/P9ea2/19n1eqc0mv9W2uKLZg5K6SCQKh46X4FX/Y EyidPbytkWKOM6Z8AoYH+jZCCwcvKpxVTJvOTLobXRglBIHJZeu9WGEtTpxkHsgquTSp 0LkAK0fMNhojRQ/PThX7PXJGvZRrARK47nwX8Tnj8WHez9XmFZl3C6wumUN/EKV8JJVu CDtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704475417; x=1705080217; h=content-transfer-encoding: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=4HRD1m75rmyzSkd8n86RMikU1s+/iGWMK24uEirNsM0=; b=H4iyc7QgjvPHKuX8cicm3KXUsLtPYrbSngpgKR2Q7G7ZCoMHhKjPQAmhgNpmhrOnPu Vnu2OmdVu4Z95fTQgZc9S2bNLqJV7FCC65KaoPa80GSCGkuCVv/emYW4IxeliD8kT834 HsEF9Ix0cbZZ9lvg/oj986E/g9b0pdMUtONSITOe4Bt4EOLf2SlyjCn8lylybpSGgQsI qCZRjqS9WOMfAgjXdR7S1iU6hyVguVlBSF+9TTOuqAYHYL4mBshbQOZGyXKA49muBNwZ eZSkqUXW/+dK4oK9Y1k7ZXa4g3gTjsEfuOQAh+I9/Dq/HKDwyRVOOhiG02ZH6ZLw0qvV 8lkw== X-Gm-Message-State: AOJu0Yw9Z5lNcbP3ahf++FJLX3ZFPe1MB8l6ZFif9emTePCgpVu0rQsS EKT2gyXRz74EIZhaWUEx3JWNrGe3JcqPQeV2OMc= X-Google-Smtp-Source: AGHT+IF0eLEcy7dRvFKqk2HU57Ob34H5WDa5/qx4RkDbUwemf/1wKhqSxWzYeH9Cr3TcQuIRrdZUA4sUw6OWzaSJQts= X-Received: by 2002:a17:906:6d3:b0:a28:5597:6253 with SMTP id v19-20020a17090606d300b00a2855976253mr1289807ejb.21.1704475417113; Fri, 05 Jan 2024 09:23:37 -0800 (PST) MIME-Version: 1.0 References: <1661334672.728714027@f473.i.mail.ru> <485cf2a2-d504-fb5f-6751-1085ccf614ec@mail.ru> <4530546a-3216-eaa9-4c92-92d33290a211@mail.ru> <6b48c746-9704-46dc-b9be-01fe4137c824@iki.fi> In-Reply-To: <6b48c746-9704-46dc-b9be-01fe4137c824@iki.fi> From: Robert Haas Date: Fri, 5 Jan 2024 12:23:25 -0500 Message-ID: Subject: Re: Stack overflow issue To: Heikki Linnakangas Cc: Egor Chindyaskin , Sascha Kuhl , pgsql-hackers@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Nov 24, 2023 at 10:47=E2=80=AFAM Heikki Linnakangas wrote: > What do you think? At least for 0001 and 0002, I think we should just add the stack depth chec= ks. With regard to 0001, CommitTransactionCommand() and friends are hard enough to understand as it is; they need "goto" like I need an extra hole in my head. With regard to 0002, this function isn't sufficiently important to justify adding special-case code for an extremely rare event. We should just handle it the way we do in general. I agree that in the memory-context case it might be worth expending some more code to be more clever. But I probably wouldn't do that for MemoryContextStats(); check_stack_depth() seems fine for that one. In general, I think we should try to keep the number of places that handle stack overflow in "special" ways as small as possible. --=20 Robert Haas EDB: http://www.enterprisedb.com