Re: Transaction ID wraparound, Oracle style

Поиск
Список
Период
Сортировка
Искать
От
A.M.
Тема
Re: Transaction ID wraparound, Oracle style
Дата
Msg-id
A3162628-15FC-4221-8801-6C3C1F61B7B9@themactionfaction.com
Ответ на
Список
Дерево обсуждения
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 по дате отправления
От: Scott Marlowe
Дата:
От: Simon Riggs
Дата:
FAQ