Re: Transaction ID wraparound, Oracle style
От | Scott Marlowe |
---|---|
Тема | Re: Transaction ID wraparound, Oracle style |
Дата | |
Msg-id | CAOR=d=2WGFA19qPqVsKhmYHNQ+sPnokS02JFRgKcYR5dXs_JRQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Transaction ID wraparound, Oracle style (Igor Polishchuk <igor@powerreviews.com>) |
Ответы |
Re: Transaction ID wraparound, Oracle style
|
Список | pgsql-general |
On Wed, Jan 18, 2012 at 11:21 AM, Igor Polishchuk <igor@powerreviews.com> wrote: > Here is an article on a recently discovered Oracle flaw, which allows SCN to > reach its limit. > http://www.computerworld.com/s/article/9223506/Fundamental_Oracle_flaw_revea > led?taxonomyId=18&pageNumber=1 > > Please don't beat me for posting a link for an Oracle related article. > If you despise a very notion of mentioning Oracle, please just don't read > the post. > This article may be interesting to any RDBMS professional, no mater what db > flavor he/she is working with. > Also, this story may be a lesson for the Postgresql community on how not do > things. I'm not a developer, but it seems that having synchronized > transaction id between let say streaming-replicated databases would give > some advantages if done properly. Wow, interesting difference between postgresql which occasionally resets its smaller transaction id to prevent wrap whereas oracle just uses a bigger number. If my calcs are right, Oracle has about 500 years to figure out the wrap around limit at 16ktps etc. Thanks for the link, it was a fascinating read. -- To understand recursion, one must first understand recursion.
В списке pgsql-general по дате отправления: