Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)
От | Andres Freund |
---|---|
Тема | Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors) |
Дата | |
Msg-id | 20160510210937.bwinj3oewawinqsl@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors) (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | 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 по дате отправления: