Re: Proposal: Commit timestamp
От | Zeugswetter Andreas ADI SD |
---|---|
Тема | Re: Proposal: Commit timestamp |
Дата | |
Msg-id | E1539E0ED7043848906A8FF995BDA57901C13135@m0143.s-mxs.net обсуждение исходный текст |
Ответ на | Re: Proposal: Commit timestamp (Jan Wieck <JanWieck@Yahoo.com>) |
Список | pgsql-hackers |
> Yes, yes, and yes ... but aside from the problem that you use the very > ambiguous word "timestamp" (which somehow suggests using a "clock" of > some sort), isn't the "begin" timestamp of a long running transaction imho a begin timestamp is near useless > worse than the "commit" timestamp, when all its work got visible to the > outside world instantaneously? This is one of the areas I am still worried about. Is one commit lamport timestamp enough ? I think for some conflict resolutions we need to look at the row level, and resolve conflicts per row and not per transaction (yes, this means that a tx might get partially replicated). What I am trying to lead at is: maybe an infrastructure to produce wieck lamport timestamps, that can be used in different places like commit hooks and column defaults, would be of more general use. Maybe such a column could be a system column that is not visible with "select *" for those cases where commit is not enough. And a commit hook could insert it into clog like storage. Andreas
В списке pgsql-hackers по дате отправления: