Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)
| От | Alvaro Herrera |
|---|---|
| Тема | Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors) |
| Дата | |
| Msg-id | 20160510182039.GA561066@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)
Re: HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors) |
| Список | pgsql-hackers |
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. > 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. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: