Re: Transaction ID wraparound, Oracle style
От | A.M. |
---|---|
Тема | Re: Transaction ID wraparound, Oracle style |
Дата | |
Msg-id | A3162628-15FC-4221-8801-6C3C1F61B7B9@themactionfaction.com обсуждение исходный текст |
Ответ на | Re: Transaction ID wraparound, Oracle style (Scott Marlowe <scott.marlowe@gmail.com>) |
Список | pgsql-general |
On Jan 18, 2012, at 2:15 PM, Scott Marlowe wrote: > 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. By the way, this is called a Lamport clock. http://en.wikipedia.org/wiki/Lamport_timestamps?banner=none "On receiving a message, the receiver process sets its counter to be greater than the maximum of its own value and the receivedvalue before it considers the message received." Cheers, M
В списке pgsql-general по дате отправления: