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 1whqaV-000SA7-0m for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jul 2026 15:22:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1whqaT-00DZ5U-2M for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Jul 2026 15:22:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1whqaT-00DZ5M-0z for pgsql-hackers@lists.postgresql.org; Thu, 09 Jul 2026 15:22:54 +0000 Received: from mail-oa1-x35.google.com ([2001:4860:4864:20::35]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1whqaQ-00000000Unz-3i7B for pgsql-hackers@postgresql.org; Thu, 09 Jul 2026 15:22:53 +0000 Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-448b89f700fso1011978fac.2 for ; Thu, 09 Jul 2026 08:22:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783610570; cv=none; d=google.com; s=arc-20260327; b=DG7dsrJ3/71O9ENzzPqMgTGMJ2IOxZsUEPU3z7tD+ogI3e3/KbhC4ivBZDM5JiJEwg pwqWNgi69Zg9Q4sJ0lQSqfb5tPpIdMd9K3Pa59Ipl+A2OeQY1+ep083enuTZDpkMklxh SuXZMLdmZjG3Yvsq9RjmNiNt+jqsT0TfktAIc428WZAHFMTBVrxdLuDZGuLuza1xr/x9 JQu7nua9TJ5dFcUYFpkNx231eUpEKIDIFZV+Qd4dPmHNKI2CyN7FavZppbrg63Qcfa+Z qu0V3yFftopTC18N/mjra/6z/tXhGYwWMX0EbLOP5wyHUIKpQ/tRpDHBk+240RtmZnGz l1Iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=aJyoTy2XCLYbCtYzxqU5GhEHUQsdW/ag5t/vomLGm+Y=; fh=8LDOZkS0nSq9fErLUp/+Tx+OxaKoXeQdMyAJ0zsdfTU=; b=NDjqx4HjTrI5xT8CLnVedo2QJTHTt17ChOboAu0ppyUtqi+6079k1NQXWiSO/hxOQT 0LN0k0opfGRBP8Jcj7djJ3Wk1xOAlwuHYHFU0gWi2dFXsI7Q7YH4236JaaVb+94j4LuQ hL3zW/xYe/Lg4j3gpdBOAG2EBUXecgmeeTnFaB+VfuEjHTh4WF/j+frf6lu4GvNwS8jZ KXjRD9fKkrgEXNXFws47uqo6GvMvxbzmQr7ve4pMChSBpz94BGK9bBpKvG+fKn87wgC3 ZW26nlVj3gO6W3sColEx2n9F9fYVBNaJzfQWXUHsHm0/VQmuDhetgq32QO+iJLte0lnJ 0SWw==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=illuminatedcomputing-com.20251104.gappssmtp.com; s=20251104; t=1783610570; x=1784215370; darn=postgresql.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=aJyoTy2XCLYbCtYzxqU5GhEHUQsdW/ag5t/vomLGm+Y=; b=qGF9t4gm9R5yfg7vmyyOkxImgPyvlYiAdXpnVDhF712x8ZoBO0hP6Hbg6s32th/3aE 4MkBcnBlAosh6HBHikPmbNN9PAtTyVkcmXR/REiupBJoVGIfPX5XebBLCwEls0HuezVv qPrPJUxpY9C3noIKIReBd4vnA9qIoG5/SEoxk51xXwQvXLp9KIixJ0LlgU4QEhZRFLl7 dGQNbcFttOeYta5oxhAdfjXrF85mMjby0qUprLZmLkxE5BuRdISoeOq5zIdnwcZ7DfgJ 6tSFKx0/A0Zd5U5Bl+e3q8At5XNFJKinf7XStXNHPv1C53GgTPo1wGxLcGT+T8fHj8rl oHvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783610570; x=1784215370; h=content-transfer-encoding:content-type: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 :content-type; bh=aJyoTy2XCLYbCtYzxqU5GhEHUQsdW/ag5t/vomLGm+Y=; b=GVNZl7rsY1KQEVyEo3a2PaA2Uo2IPQz1CpGsgma5SjPN6i9/gjuAl7nHmaHrRVLQrH NLICE8oerH0H2N19EWR0aVPyYkZxByEM4UKhLmvrjmKtcq4Nzf7p8psvM/8XRlT2TfHE Aiv2+mwtq8xDnCG4b0GBMbOE+7njinOYC89XJTfiMaGpKh4UmgWB/klx9c7sWYXdMGvy mpeYLluIHsSc3GckH2Q0KhF6HXOVEEJMOV3GQjiYgPN/9Vg6eMhhINFPdseAw1eSIGib fI0Uv9QCi/oM4wGbwYjmCqVhmR/+IBfVRCnAWlM1Oiu/5HUNpM/5wBp0TnACB8EJSM0J 6IjA== X-Forwarded-Encrypted: i=1; AFNElJ/EL3vo333IUvaTNtXRTSA04TmO8v7SMjs7Qyjofkv5asSHEvkmzBYghvAdxZJieyAZiOwoDpmDuv4ZCImh@postgresql.org X-Gm-Message-State: AOJu0YycM48LPrKJ9w3ZagRDdSApvZTqaa8GDqbXc9U9F4iX5W58D8fz 7xR0Q7JYS/3RnJNieMVj3rJKdQItWaS/H/wTr+q9ggu/6J+zHoQhmr9VCF86XohEwT+ijmhvpT9 MfZAxyvHqPqz5BgO9BntP21/Rv1acKUGeMG1stCvMG0BWVDR3yA4odAhb7w== X-Gm-Gg: AfdE7cnpnzVzJTpBZJqd4GhjUbcSiSnyvY8Z3QQV2dLoaFZyFpYZpaSqv3mewupkdeb 2G9+VXg8D8nQysAvaYZ1B7XrumYjTkJM3l2qUzmb8UEEe768GlPYjTwWJVvbzW1FDDGdrBtgC7J xqU7aQ4zjCCdgL57Xl8GF76rQ+uTcReunJPaj9hoaY2IdhVi0j88PWl530VQ/RFFd/Q8hEwo10k 8idmdRM1HAklmS8oknKGqBZNFEUpscBMgQqPokMa/DOf8HyOPTROPix3QOx+26/vJbQ3IaO X-Received: by 2002:a05:6808:30cd:b0:4a4:935:2b07 with SMTP id 5614622812f47-4a4093561aemr454552b6e.24.1783610569578; Thu, 09 Jul 2026 08:22:49 -0700 (PDT) MIME-Version: 1.0 References: <626986.1776785090@sss.pgh.pa.us> <84f20d0d-3bc8-4843-bd7e-21bce20f8582@eisentraut.org> <4984118e-0dc5-49a9-b279-fd0b707be8e0@eisentraut.org> <391a2845-105b-4048-a113-835c2742fea1@eisentraut.org> <1894792.1783476457@sss.pgh.pa.us> <82f35e5c-9983-4c97-8567-451bc2cb8761@eisentraut.org> In-Reply-To: <82f35e5c-9983-4c97-8567-451bc2cb8761@eisentraut.org> From: Paul A Jungwirth Date: Thu, 9 Jul 2026 08:22:38 -0700 X-Gm-Features: AVVi8Cd_lGcHaRaDZ0KKCMEP7UmmuY2NCuMuZQOX4wTHuVe-FV8jHHdSEQhR2Pk Message-ID: Subject: Re: [PATCH] Fix null pointer dereference in PG19 To: Peter Eisentraut Cc: Tom Lane , Aleksander Alekseev , PostgreSQL Development 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 Thu, Jul 9, 2026 at 1:32=E2=80=AFAM Peter Eisentraut wrote: > > > Here is another patch series. No code changes, but I inserted a new > > patch with tests showing that parse-time checking crashes, but > > rewrite-time and exec-time checking catches the forbidden statement. > > So the series is: > > > > v1: parse-time check, tests pass > > v2: add tests that crash the server > > v3: rewrite-time check: tests pass > > v4: exec-time check: tests pass > > What do you want to do with these? Here you list them as four different > versions, but the attachments are four incremental patches of the same > version. Do you propose to apply all of them? > > It seems we definitely do want the exec-time check. And I can see maybe > the parse-time check as an additional user-friendliness feature. But > maybe we don't need to check three times? I should have called them part{1-4} instead of v{1-4}. My intent is to squash them, but I thought separating the changes clarified the problem and how v3/v4 fix it. Either squash v1-3 if you want to check at rewrite time, or v1-4 if you want to check at exec time. Each part removes the check from the prior part, so there is only one check, it's just a question of when we do it. Checking at v1 is Aleksander's original patch. Then v2 adds tests that crash the server. v3 moves the check to rewrite time, and the tests pass. v4 moves the check again to exec time. But v4 is a behavior change: an UPDATE that touches zero rows no longer fails. I thought that was weird; that's why I recommended leaving it out (in https://www.postgresql.org/message-id/CA%2BrenyXPEJYOVov3XtzTp3NusGkObc9UeW= -Nm78K8_nsWSnnfg%40mail.gmail.com before I added the crashing tests). I like your idea of keeping the parse-time check too. Then we can show line numbers. Want a patch with that? If we check at both rewrite-time and exec-time, the exec-time check will never happen (as far as I can tell). If we want something there, maybe it should be an Assert or an elog. I can give you one squashed file if you like. After reading your email, my preference is to check at parse time, check again at rewrite time, and Assert at exec time. Yours, --=20 Paul ~{:-) pj@illuminatedcomputing.com