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.96) (envelope-from ) id 1w6zlS-004r8t-0M for pgsql-bugs@arkaria.postgresql.org; Sun, 29 Mar 2026 23:41:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w6zlQ-00016j-1X for pgsql-bugs@arkaria.postgresql.org; Sun, 29 Mar 2026 23:41:52 +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.96) (envelope-from ) id 1w6zlQ-00016T-0j for pgsql-bugs@lists.postgresql.org; Sun, 29 Mar 2026 23:41:52 +0000 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w6zlO-00000001iRT-3Xcr for pgsql-bugs@lists.postgresql.org; Sun, 29 Mar 2026 23:41:51 +0000 Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-43b41b545d9so4227309f8f.2 for ; Sun, 29 Mar 2026 16:41:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774827709; cv=none; d=google.com; s=arc-20240605; b=Pude+OkrunTNXeyb6D4BfAV5DjePS4kuwTC62fBL75sKdnuzfUVI6ZRvYMuSz+DPI+ ScCphsOyx2ayR9nuQsrxtL5yW3F8cMZlfaf1qfPSJUCYYppSquGsTuPN1aZNVKS1EHAQ P2Nl0cv8lkG1hSKmQG7QKQiqrDkcSuVSXxhRaV8SoK4VLxLf43lVfp6hQQVgBM/Pm5Bk GsA3P5VEWI+QuxDkm8BC6Pc/iVG/9bj/gOydZbRLhuulLr9nndgbDifj5lJKv7QG26j9 w5fiH1P2YAb9GN7Sf710SSSvIBr8aR58sUi7gNWblVWOBwcsNHTk7KmwQRUs+9+MiFdG S3fw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=HoqQFj2oPzf86ckOcW2VBztsCEFEigI8cwyol5dOlJA=; fh=MGSBDroCXXk7aFMbwTC+n5iZLBFrEnE56Ulr5nz1tu0=; b=N7HnBATM3dqLlzWlGZ0PYRuwmgVu67wsiFUgb8B/xHHxgK3NTfaUZG174DEfKNqsOZ MBCPhf08CNfCLPUTatQZMOBnEAH3gKfTHg7KXRXyQ8Yo6DmM50UgOiTu1qoFbzo3OwyO ndu1aGjBaWCXmipDcBB8cIYqu5R7k0MjDeZwtsrIxJMxxX+m7uD7Z0B+eWmx/Ht1mKq9 tyMCSD9hq3V1m8xv4FT36kBAtg3pWr5JYidtWy0WZgj/Be+m4jdGsotFvfdgmiMn0JF0 6QdysOGFu34NKq4V4qEIrOoAoKFV1AqtNcP0SzatqPGUB+c+lti5wlkE7pyu3UMxdidG 4KTw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774827709; x=1775432509; 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=HoqQFj2oPzf86ckOcW2VBztsCEFEigI8cwyol5dOlJA=; b=NKeOWoEhJpJmFL4SZ9hRho06amrvLa1xSX/iNXccTr/aeZTTNRYP1eEdpAPScaERyA liqL1rvopOvpmoYx6esOQrmw6Mh4Dv3dAvwe0UOPUokEvUE/J16/YOYV9CB+1af2PeV7 La7RChSNRROH2j2o09uYwCuIj85w3XifXP49LrPREjOS3gpFb8McUi3X8zPcBMtwfgTl QbwLL1CFukJqYIASdBfL8Kx0kD60Kr96Ca5HXBCnG/lYnD1PNc3cfjtROoimMICUME5E kIQe+rjo/bzGtQItAz09gTqGWaSiXhIopfB8jMJ784Y2CMJrhOTaWM4mXTpCRCCTnpCw xVnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774827709; x=1775432509; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HoqQFj2oPzf86ckOcW2VBztsCEFEigI8cwyol5dOlJA=; b=ZhJ5Duqtc1rq/mqv0QhhPO/jUAzsCnvuovHlr46Vnc6Gr0l58xzi2NWxz8QUql4v09 HgHPwLCSern6GqMBhKjP+ZsAxEl4K2Yoeml8u7Xm4yE/xbG7yUAW2NYRv9ijhhxEGIZ2 urPzzalnNfj+78r+FNJSOHEXZMvXctX35a4vLBZ4rJ+o7D3GiZD1MSklqlghAsmvML/P 8PgidZA6HqRbfatKBYTTs8QFjYkyVGHU871iXT8cUeOsYRVyA/CBYnOrBH7+Y6aETiW9 4xHHIZ10FJuoJnTLPF+ZnMMZUs8qdbXwH1VFui1nXBq0TlV4tbsnncnNHezKjLQ2PotD smSA== X-Forwarded-Encrypted: i=1; AJvYcCXxtmPITXTfVlVfcNKgA3SE+IxYU5oO36ujhEJlkGHkr6TL0tnvKyh5oZ7aZFIFq0iu3fjKpPUxAn9q@lists.postgresql.org X-Gm-Message-State: AOJu0YxHY8T4EB/wNicZSGivBQcowdaH/DQGhmFIarqxofPGyviVOt9l 7EH5jgRVGHyMHbgFmKhrxSuW1J2rlLVGCIS9d4BCSr6bC0TzARYXSOZ9Z52GomDxReYjHGku5Yc M8QSsDrtL2sDVcOh16Hp9HFfmUaGKkS8= X-Gm-Gg: ATEYQzwwlxim0l3dg+CsidtQLyMi4skAT+2q4raAK0GFfDhJ8yX/UGyDS31Qa815y50 8uekblcpD8vK4l7t3SR9LdBxLA2CXM33WQRQYf8qJm5eFRQlLAVaYwDVIW8BbDh53VPwcWdxxym Jk7DWfKA5JR7W2N8VDwBQgSz6BWF0iWT7G8t2sOrRsaYSNH6KDwAVpIFQhpLvHpIg4M3+xi//S7 KW5b1c+R0jrzO1pBL9JWDNXnVNCL9eLRIFKJx8myd0YKSsliGWJE+OEBJXk2DRv8HUNssmuNoPy /r8CxQFK+C7HrmoC249zA9qnY1MjjXaSqwhiYaPRRCbPYbHvj/7fognVEplka4ZCzPy0uKiDFWx YGD4iWLJc X-Received: by 2002:a05:6000:2006:b0:43b:86ce:27a1 with SMTP id ffacd0b85a97d-43b9e9ea409mr18638797f8f.17.1774827709208; Sun, 29 Mar 2026 16:41:49 -0700 (PDT) MIME-Version: 1.0 References: <19438-9d37b179c56d43aa@postgresql.org> <1106026.1774573371@sss.pgh.pa.us> <1338824.1774633289@sss.pgh.pa.us> <1830345.1774798374@sss.pgh.pa.us> In-Reply-To: <1830345.1774798374@sss.pgh.pa.us> From: David Rowley Date: Mon, 30 Mar 2026 12:41:37 +1300 X-Gm-Features: AQROBzAtkQL-nxEpni-CyKe8JxgIUxR7_esnQWgaHhbpk3nYUN9wNV-iaIrxL8k Message-ID: Subject: Re: BUG #19438: segfault with temp_file_limit inside cursor To: Tom Lane Cc: kuzmin.db4@gmail.com, pgsql-bugs@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, 30 Mar 2026 at 04:32, Tom Lane wrote: > Here's a fleshed-out version of the requested_size method. > I noted that AllocSetRealloc needs a defense too, and then > extended the patch to generation.c and slab.c. bump.c > doesn't have an issue, and I don't think alignedalloc.c > needs its own defense either: it can rely on the underlying > context type. Thanks for writing that up. I looked at the code and tested. The only thing that I noted was GenerationFree(), where we do: /* Test for previously-freed chunk */ if (unlikely(chunk->requested_size == InvalidAllocSize)) elog(WARNING, "detected double pfree in %s %p", ((MemoryContext) block->context)->name, chunk); /* Test for someone scribbling on unused space in chunk */ Assert(chunk->requested_size < chunksize); I expect you've likely thought of this, but if we do spit out the warning there, then the Assert is definitely going to fail, as InvalidAllocSize is defined as SIZE_MAX. I don't know if that means it's worth deviating from the similar WARNINGs you've added and making that one an ERROR. There's certainly no guarantee with the other context that we'll not crash sometime very soon after issuing the warning anyway, so maybe it's fine. David