On 2016-05-10 16:14:50 -0400, Tom Lane wrote:
> I think the problem is pretty hypothetical until you get to consuming a
> substantial part of the OID space within any one toast table, at which
> point you're going to need 8-byte toast OIDs. Improving that situation
> seems like something we can define as a future feature.
Doesn't really have to be within a single toast table. As the oid
counter is global, it just needs to advance quickly enough globally.
> (Note that I do not believe for a moment that Andres has actually
> exhibited such a problem in his test case. He'd have needed several
> TB worth of TOAST space to get to that point.)
That's good, because I explicitly said that there was no wraparound
involved in the test case.
> >> In principle, you could support existing TOAST tables and pointers
> >> containing 4-byte IDs in parallel with the new ones. Not sure how
> >> pg_upgrade would handle it exactly though.
> > I suppose the real problem is that there's no way to have a mix of 4-
> > and 8-byte identifiers in the same toast table. I suppose we could have
> > two toast tables for each regular table, but that sounds pretty painful.
> Hmm. It's not impossible by any means, since you could tell by looking
> at a toast OID which table it was in. And that way might provide a less
> painful upgrade process for an existing table that grew to the point of
> needing bigger OIDs.
The catalog representation (as in pg_class.reltoastrelid) isn't entirely
clear to me. One way would be to invert pg_class.reltoastrelid's
meaning and have the toast table point to the table it stores values
for. That'd also open the potential of having one toast table per column
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: