Re: Support for 8-byte TOAST values, round two

From: Oleg Bartunov <obartunov(at)postgrespro(dot)ru>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support for 8-byte TOAST values, round two
Date: 2026-09-14 01:39:34
Message-ID: 72d00c47-33e4-4d35-9a3c-b335ef344afd@email.android.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

<div dir='auto'><div><br><div><br><div class="elided-text">On Sep 14, 2026 05:02, Michael Paquier &lt;michael(at)paquier(dot)xyz&gt; wrote:<br type="attribution"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">On Sun, Sep 13, 2026 at 10:07:27PM +0545, Oleg Bartunov wrote:
<br>
&gt; I did a quick check of out-of-tree users and found at least two
<br>
&gt; examples. PostGIS has code like this in ToastCacheGetGeometry():
<br>

<br>
postgis holds a direct reference to varatt_external in its
<br>
libpgcommon/lwgeom_cache.c, which is wanted to feed data to
<br>
ToastCacheArgument.&nbsp; As far as I can see, their change is not
<br>
complicated, upgrade ToastCacheArgument.valueid to be an Oid8, then,
<br>
instead of the direct use of varatt_external() switch to a
<br>
toast_external_data combined with a call of toast_external_info_get()
<br>
to make the switch transparent, so as the TOAST value, Oid or Oid8 can
<br>
be retrieved.
<br>

<br>
So it's not a complicated change, and as far as I can see it's mostly
<br>
a matter of two PG_VERSION_NUM blocks plus a few tests.&nbsp; Using
<br>
varatt_external in the code would lead to a compilation failure,
<br>
because it's now renamed varatt_external_oid, one will not see a
<br>
runtime failure.&nbsp; It's going to be hard to miss that something is
<br>
wrong in this case.
<br>

<br>
&gt; MobilityDB carries the same pattern. So an OID8 datum can now pass
<br>
&gt; VARATT_IS_EXTERNAL_ONDISK() and existing code can then interpret it
<br>
&gt; using the old OID pointer layout.
<br>

<br>
EXTERNAL_ONDISK() means either of them.
<br>

<br>
&gt; I noticed this because we have been experimenting with alternative
<br>
&gt; physical representations of large varlena values and tracing which
<br>
&gt; parts of the value lifecycle actually depend on a particular TOAST
<br>
&gt; representation. OID8 turned out to be a useful real-world test of that
<br>
&gt; boundary.
<br>

<br>
MobilityDB is carrying the same patterns because it uses a copy-paste
<br>
of the postgis code.&nbsp; Again, this uses directly varatt_external, which
<br>
would fail at compilation under PG20.&nbsp; It sounds to me that they just
<br>
update their code on a regular basis based on postgis, so it means
<br>
that sending only a patch to adjust postgis would be enough.&nbsp; I'm
<br>
happy to take some time to do that, it</p></blockquote></div></div></div><div dir="auto">Thanks, that makes sense. I had missed that the varatt_external rename turns this particular case into a compile-time failure.</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
&gt; Perhaps we need to distinguish explicitly between "any on-disk
<br>
&gt; external pointer" and "the old OID on-disk pointer", rather than
<br>
&gt; changing the meaning of the existing predicate?
<br>

<br>
It seems to me that this difference already exists in the patch, due
<br>
to the rebranding of varatt_external.
<br>

<br>
Note that if somebody has the idea to use VARTAG_SIZE() to copy
<br>
external varlena pointers, then the change is transparent.</p></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Just to make sure I understand the intended abstraction correctly: with this patch, should I think of VARATT_IS_EXTERNAL_ONDISK() as identifying a family of on-disk external representations, while the vartag identifies the concrete physical representation within that family?</div><div dir="auto">In other words:</div><div dir="auto">VARATT_IS_EXTERNAL_ONDISK() -&gt; representation family, and&nbsp;</div><div dir="auto">VARTAG_* -&gt; concrete representation</div><div dir="auto">If so, that is actually the distinction I was looking for.</div><div dir="auto"><br></div><div dir="auto">Oleg&nbsp;</div><div dir="auto"><div><div class="elided-text"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">
<br>
--
<br>
Michael
<br>
</p>
</blockquote></div><br></div></div></div>

Attachment Content-Type Size
unknown_filename text/html 4.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jinqing Kuang 2026-09-14 01:42:13 Re: postgres_fdw: push down FETCH FIRST .. WITH TIES when server version allows
Previous Message Michael Paquier 2026-09-14 00:46:12 Re: Support for 8-byte TOAST values, round two