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 по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Ooops ... seems we need a re-release pronto
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Reduce WAL activity for page splits: > Currently, an index split