Re: OID wraparound: summary and proposal
| От | Hannu Krosing |
|---|---|
| Тема | Re: OID wraparound: summary and proposal |
| Дата | |
| Msg-id | 3B719EBF.12410A49@tm.ee обсуждение исходный текст |
| Ответ на | Re: Re: AW: Re: OID wraparound: summary and proposal (Alex Pilosov <alex@pilosoft.com>) |
| Список | pgsql-hackers |
Tom Lane wrote: > > Fernando Nasser <fnasser@redhat.com> writes: > > The wire protocol will always handle the (tableoid) long form, > > I think you are handwaving away what is precisely the most painful > aspect. To allow 64-bit type OIDs in the wire protocol, we must > (a) have a protocol version jump, and (b) force all servers and all > client libraries to be 64-bit-capable. While I'm prepared to think > that "int8 is really only 32 bits wide" is tolerable within a single > server installation, I really don't want to deal with such headaches > between clients and servers. Can you imagine how hard it will be > to track down a bug that arises because one old client is dropping > the high-order bits of type OIDs? When I thought of it, my solution was to issue a NOTICE on each and very OID truncation - they should be visible enough to force upgrade ;) > Only installations that had been > up for years would ever see a problem; how likely is it that anyone > would even remember that some of their clients were not 64-bit-ready? > > When we're ready to make that jump, I think we should just move to > 64 bit OIDs, full stop, no exceptions, no turning back, no "configure > time option", no backwards compatibility with old clients. Anything > else is a time bomb. I'd even be inclined to start running the OID > counter at 4-billion-plus-1, to help flush out anyplace that drops the > high half. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
В списке pgsql-hackers по дате отправления: