public inbox for [email protected]
help / color / mirror / Atom feedFrom: Junwang Zhao <[email protected]>
To: David Rowley <[email protected]>
Cc: Tender Wang <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: John Naylor <[email protected]>
Cc: PostgreSQL Developers <[email protected]>
Subject: Re: More speedups for tuple deformation
Date: Tue, 17 Mar 2026 00:37:56 +0800
Message-ID: <CAEG8a3+cpoPG9bCX-65Y=VqKrZDvWd2ADLt-1qGyvDAWfL6Qkw@mail.gmail.com> (raw)
In-Reply-To: <CAApHDvrFmW+2GhdDKuWRaJmp8MfghmBiEGaeqjOD_Y2RWUFSow@mail.gmail.com>
References: <CAApHDvpbntG7V3_EsZ+w-V=jU-y8rFmv9RB1EDJm4sxKno-4UA@mail.gmail.com>
<e7sto7tk5dk5hfyvoocaddnxcngemcmfvbuh23l32w5cssaizy@znuphjqug7qe>
<CAApHDvpuEbhvH1ViCZRz5vks+_bGbEnPoEdZYAZXK76_isb_+Q@mail.gmail.com>
<v6z545yozjtywghn5glujemu72z4i4ynadsc2xks4ejotdg7yl@4rry7ixwr4us>
<CANWCAZabO1oj+khF+YNVpmkTQwRRyNJesbsBhRFL5emZJh3tow@mail.gmail.com>
<lzgoxzbh2gel5w362revuwaecrsbjr44kjdzrewuejugcodkeq@ixymojwnylsy>
<CAApHDvodSVBj3ypOYbYUCJX+NWL=VZs63RNBQ_FxB_F+6QXF-A@mail.gmail.com>
<rbxc2qqhsvzxpukgd36caoa4ydgn5r22fxktxanrkn6nobg7j6@27b4vogohgu2>
<CAApHDvpWQn8sXDYpSNNpieJW-UTG4Nf4TVjT8ew64L073hz-Fw@mail.gmail.com>
<mq6ddpgctt42srolsvo5kph2s6shfg62meb7i5fbg6n3s73zju@2n7gviiyga3h>
<uhqul2ryci4tyg5ylddjrmf4kybzwb7m5z7rmurhhjp37vrn5f@zgxil7egr62n>
<CAApHDvq21qQigiM6z2YgadFusQC_pfEYP8D=oQCrwJ_kKzcqDg@mail.gmail.com>
<CAApHDvpdB1t7LCgH8=KOKC6VBb2rsEbaas0FiXo5awsRgCsDxQ@mail.gmail.com>
<CAEG8a3KeKcZxJsH9nL+D1JzC4Ekx51ps7-1ZGWkwdXbPS5jTXw@mail.gmail.com>
<CAApHDvqp_DGNkz3Rr29hPuSYdai5c_32mWSv2inrW2ufsE+qZQ@mail.gmail.com>
<CAHewXNnb-s_=VdVUZ9h7dPA0u3hxV8x2aU3obZytnqQZ_MiROA@mail.gmail.com>
<CAApHDvrFmW+2GhdDKuWRaJmp8MfghmBiEGaeqjOD_Y2RWUFSow@mail.gmail.com>
Hi David and Tender,
On Mon, Mar 16, 2026 at 5:17 PM David Rowley <[email protected]> wrote:
>
> On Mon, 16 Mar 2026 at 20:01, Tender Wang <[email protected]> wrote:
> > SELECT * FROM t2, t4 RIGHT OUTER JOIN t0 ON t4.c0 WHERE t4.c1 ORDER BY
>
> > server closed the connection unexpectedly
>
> Thanks. Looks like I didn't get the startAttr logic correct in
> nocachegetattr(). Starting by using the attcacheoff of the first NULL
> attribute isn't valid. It should be the attribute prior to that one.
>
> I'm just verifying some code locally now.
>
> David
>
>
The following case is more simpler:
drop table if exists ty;
create table ty(c0 int not null, c1 double precision, c2 int4range);
insert into ty values (1, 1.0, '[1469060470,1895771979)');
insert into ty values(2, null, '[-1973503943,635641598)');
select * from ty order by c2;
In this case, firstNonCachedOffsetAttr is 2 and firstNullAttr is 1.
If we start from 1, the cached offset becomes 8 due to double's
alignby, and deforming int4range from offset 8 will lead to corrupted data.
Therefore, as David said, we should start from the attribute prior
to that one. PFA is a trivial fix, I think we should add the test but
I haven't found a proper regress test file for it.
--
Regards
Junwang Zhao
Attachments:
[application/octet-stream] 0001-Fix-startAttr-computation-for-nocache-attribute-fetc.patch (1.7K, 2-0001-Fix-startAttr-computation-for-nocache-attribute-fetc.patch)
download | inline diff:
From d4b36daa6ddefae4e3548886f337d11ce284e692 Mon Sep 17 00:00:00 2001
From: Junwang Zhao <[email protected]>
Date: Tue, 17 Mar 2026 00:26:49 +0800
Subject: [PATCH] Fix startAttr computation for nocache attribute fetch
Adjust nocache[heap|index]_getattr() to base the starting attcacheoff
on the attribute before the first NULL, ensuring cached offsets are
valid.
---
src/backend/access/common/heaptuple.c | 2 +-
src/backend/access/common/indextuple.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/backend/access/common/heaptuple.c b/src/backend/access/common/heaptuple.c
index 26f0c3bb2c4..31f64b0a31a 100644
--- a/src/backend/access/common/heaptuple.c
+++ b/src/backend/access/common/heaptuple.c
@@ -541,7 +541,7 @@ nocachegetattr(HeapTuple tup,
* Start at the highest attcacheoff attribute with no NULLs in prior
* attributes.
*/
- startAttr = Min(tupleDesc->firstNonCachedOffsetAttr - 1, firstNullAttr);
+ startAttr = Min(tupleDesc->firstNonCachedOffsetAttr - 1, Max(0, firstNullAttr - 1));
off = TupleDescCompactAttr(tupleDesc, startAttr)->attcacheoff;
}
else
diff --git a/src/backend/access/common/indextuple.c b/src/backend/access/common/indextuple.c
index 6ba09932ba6..7d0cf9b3ba7 100644
--- a/src/backend/access/common/indextuple.c
+++ b/src/backend/access/common/indextuple.c
@@ -267,7 +267,7 @@ nocache_index_getattr(IndexTuple tup,
* Start at the highest attcacheoff attribute with no NULLs in prior
* attributes.
*/
- startAttr = Min(tupleDesc->firstNonCachedOffsetAttr - 1, firstNullAttr);
+ startAttr = Min(tupleDesc->firstNonCachedOffsetAttr - 1, Max(0, firstNullAttr - 1));
off = TupleDescCompactAttr(tupleDesc, startAttr)->attcacheoff;
}
else
--
2.41.0
view thread (31+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: More speedups for tuple deformation
In-Reply-To: <CAEG8a3+cpoPG9bCX-65Y=VqKrZDvWd2ADLt-1qGyvDAWfL6Qkw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox