Re: Solving the OID-collision problem

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Solving the OID-collision problem
Дата
Msg-id 873bphbpmf.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Solving the OID-collision problem  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Solving the OID-collision problem  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:

> Just to chime in --- I have been surprised how _few_ complaints we have
> gotten about oid wraparound hitting system table oid conflicts.  I agree
> that telling people to retry their CREATE statements isn't really an
> ideal solution, and the idea of looping to find a free oid is a good one.

So in a world where all user tables have OIDs I can see this happening quite
easily. A reasonably large database could easily have 4 billion records
inserted in a reasonable amount of time.

But with no OIDs on user tables it must take a really long time for this to
happen. I mean, even if you have thousands of tables you would have to go
through thousands (many thousands even) of dump/reload cycles before you push
oid to 4 billion.

Perhaps just a periodic warning starting when the OID counter hits, say, 2
billion telling people to dump/reload their database before it gets to 4
billion would be enough?

All this stuff about retrying OIDs is cool and if someone wants to go and do
it I wouldn't say they shouldn't. But it seems like a lot of effort to avoid a
situation that I'm unclear will ever arise.

A warning could more easily be backpatched to versions that defaulted to OIDs
on user tables too.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew - Supernews
Дата:
Сообщение: Re: Simplifying wal_sync_method
Следующее
От: Andrew - Supernews
Дата:
Сообщение: Re: Solving the OID-collision problem