Horton

Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)

Jim Nasby <jnasby@upgrade.com>

View thread
From: Jim Nasby <jnasby@upgrade.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, "Burd, Greg" <greg@burd.me>, Nikita Malakhov <hukutoc@gmail.com>, Hannu Krosing <hannuk@google.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-13T20:06:16Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add data type oid8, 64-bit unsigned identifier

On Fri, Aug 8, 2025 at 4:03 PM Andres Freund <andres@anarazel.de> wrote:

> I'm not convinced that the global counter, be it a 32 or a 64 bit, approach
> has merit in general, and I'm rather sure it's the wrong thing for toast
> values. There's no straightforward path to move away from the global
> counter
> for plain oids, but I would suggest simply not using the global oid counter
> for toast IDs.
>
> A large portion of the cases I've seen where toast ID assignments were a
> problem were when the global OID counter wrapped around due to activity on
> *other* tables (and/or temporary table creation). If you instead had a
> per-toast-table sequence for assigning chunk IDs, that problem would
> largely
> vanish.
>

That's been my experience as well. I was actually toying with the idea of
simply switching from OIDs to per-table counters when I came across this,
specifically to address the problem of OID wraparound induced performance
problems.