Re: tracking commit timestamps
От | Anssi Kääriäinen |
---|---|
Тема | Re: tracking commit timestamps |
Дата | |
Msg-id | 1415175864.8931.55.camel@TTY32 обсуждение исходный текст |
Ответ на | Re: tracking commit timestamps (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: tracking commit timestamps
|
Список | pgsql-hackers |
On Tue, 2014-11-04 at 23:43 -0600, Jim Nasby wrote: > I'm worried about 2 commits in the same microsecond on the same > system, not on 2 different systems. Or, put another way, if we're > going to expose this I think it should also provide a guaranteed > unique commit ordering for a single cluster. Presumably, this > shouldn't be that hard since we do know the exact order in which > things committed. Addition of LSN when the timestamps for two transactions are exactly same isn't enough. There isn't any guarantee that a later commit gets a later timestamp than an earlier commit. In addition, I wonder if this feature would be misused. Record transaction ids to a table to find out commit order (use case could be storing historical row versions for example). Do a dump and restore on another cluster, and all the transaction ids are completely meaningless to the system. Having the ability to record commit order into an audit table would be extremely welcome, but as is, this feature doesn't provide it. - Anssi
В списке pgsql-hackers по дате отправления: