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)
Список
Дерево обсуждения
scenario with a slow query Volodymyr Kostyrko <c.kworr@gmail.com>
Re: scenario with a slow query Tom Lane <tgl@sss.pgh.pa.us>
Re: scenario with a slow query Volodymyr Kostyrko <c.kworr@gmail.com>
Transaction ID wraparound, Oracle style Igor Polishchuk <igor@powerreviews.com>
Re: Transaction ID wraparound, Oracle style Scott Marlowe <scott.marlowe@gmail.com>
Re: Transaction ID wraparound, Oracle style "A.M." <agentm@themactionfaction.com>
On Jan 18, 2012, at 2:15 PM, Scott Marlowe wrote: > On Wed, Jan 18, 2012 at 11:21 AM, Igor Polishchuk 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 received value before it considers the message received." Cheers, M
В списке pgsql-general по дате отправления
От: Simon Riggs
Дата: