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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: To be 7.1.3 or not to be 7.1.3?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: To be 7.1.3 or not to be 7.1.3?