Re: Solving the OID-collision problem

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Solving the OID-collision problem
Дата
Msg-id 1123540135.3670.439.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: Solving the OID-collision problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Solving the OID-collision problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Solving the OID-collision problem  (Andrew Sullivan <ajs@crankycanuck.ca>)
Список pgsql-hackers
On Mon, 2005-08-08 at 16:55 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > On Wed, 2005-08-03 at 19:43 -0400, Tom Lane wrote:
> >> We've sort of brushed this problem aside in the past by telling people
> >> they could just retry their transaction ... but why don't we make the
> >> database do the retrying?  I'm envisioning something like the attached
> >> quick-hack, which arranges that the pg_class and pg_type rows for tables
> >> will never be given OIDs duplicating an existing entry.
> 
> > I'd like to suggest that we backpatch this to 7.3 at least.
> 
> Considering we don't even have code to do this, much less have expended
> one day of beta testing on it, back-patching seems a bit premature.

Tom,

You provided a patch and explained your testing of it. It seems to be a
useful test to me, and as I said a practical solution to OID wrap.

OID wrap is a long-term problem for PostgreSQL installations. I'm not
sure that lots of beta testing would do any good at all, since the
proposed patch is very unlikely to occur in 8.1, and almost certainly
not during a short period of beta testing.

As I mentioned, as time goes on, this is very likely to occur with older
installations before it occurs with newer ones. Older databases tend to
have older releases, hence the comment to backpatch. I regard this as a
safety/robustness feature, just as I would other robustness fixes that
have been backpatched without a beta test phase. If we have the code it
seems strange to wait for many people to start logging complaints before
we backpatch. I can see that will only lead to PostgreSQL's robustness
falling into disrepute, rather than encouraging anyone to upgrade.

In any case, if we choose not to backpatch now, we can at least discuss
a plan for it in the future? Planning is never premature, IMHO.

Best Regards, Simon Riggs




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

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Simplifying wal_sync_method
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Simplifying wal_sync_method