Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)
Date
Msg-id 20160510210937.bwinj3oewawinqsl@alap3.anarazel.de
Whole thread Raw
In response to Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 2016-05-10 15:20:39 -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> > > On Tue, May 10, 2016 at 12:19 PM, Andres Freund <andres@anarazel.de> wrote:
> > >> It's not super likely, yea. But you don't really need to "use" 4 billion
> > >> oids to get a wraparound. Once you have a significant number of values
> > >> in various toast tables, the oid counter progresses really rather fast,
> > >> without many writes. That's because the oid counter is global, but each
> > >> individual toast write (and other things), perform checks via
> > >> GetNewOidWithIndex().
> > 
> > > Understood.
> > 
> > Sooner or later we are going to need to go to 8-byte TOAST object
> > identifiers.  Maybe we should think about doing that sooner not later
> > rather than trying to invent some anti-wraparound solution here.
> 
> Umm, it seems to me like we need this fixed in supported branches, not
> just 9.7, so I don't think 8-byte toast IDs are a reasonable solution at
> this point.

Agreed. To me it seems we need to make HeapTupleSatisfiesToast() safe,
and other improvements are tangential.

Andres



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: what to revert
Next
From: Andres Freund
Date:
Subject: Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)