Re: Packed short varlenas, what next? - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Packed short varlenas, what next?
Date
Msg-id 87zm6xs4tj.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Packed short varlenas, what next?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> I've disabled packed varlenas for user-defined data types and find tsearch2
>> and _int still fail. tsearch2 requires the small patch attached. _int seems to
>> be unrelated.
>
> As of when?  I committed fixes earlier tonight that seem to handle the
> case of VARSIZE-is-ntohl.
>
> The patch you suggest is orthogonal to what I did; it looks like it
> might be right, but regression passes without it, so what was your test
> case that led you to it?

I'm running the regression tests with the full packed varlena changes except
that I've modified it not to pack user defined data types (typid >
FirstNormalObjectId). So all varlenas need to go through detoast_datum if they
come out of a heatuple even if (especially if) they used to be too small to be
toasted.

In fact I think the line I posted is actually a bug anyways. I'm unclear what
the text field it's fetching represents and maybe it's usually small, but it
looks like there's nothing stopping it from being large enough to be toasted
in theory.

To get tsearch et al to work with packed varlena headers without disabling
them for user defined data types will require a lot more detoast_datum calls
throughout the gist data types (or defining proper GETARG macros for them).

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: VACUUM and spoiling the buffer manager cache
Next
From: Andrew Dunstan
Date:
Subject: Re: Postgres Replication