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
0001-Fix-startAttr-computation-for-nocache-attribute-fetc.patch
Description: Binary data
