Re: tracking commit timestamps

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: tracking commit timestamps
Дата
Msg-id 20141105163814.GZ28295@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: tracking commit timestamps  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
On 2014-11-05 10:34:40 -0600, Jim Nasby wrote:
> On 11/5/14, 10:30 AM, Andres Freund wrote:
> >>Except that commit time is not guaranteed unique *even on a single
> >>>system*. That's my whole point. If we're going to bother with all the
> >>>commit time machinery it seems really silly to provide a way to
> >>>uniquely order every commit.

> >Well. I think that's the misunderstanding here. That's absolutely not
> >what committs is supposed to be used for. For the replication stream
> >you'd hopefully use logical decoding. That gives you the transaction
> >data exactly in commit order.
> 
> So presumably you'd want to use logical decoding to insert into a
> table with a sequence on it, or similar?

I'm not following. I'd use logical decoding to replicate the data to
another system, thereby guaranteeing its done in commit order. Then,
when applying the data on the other side, I can detect/resolve some
forms of conflicts by looking at the timestamps of rows via committs.

> I agree, that sounds like a better way to handle this. I think it's
> worth mentioning in the docs for commit_ts, because people WILL
> mistakenly try and use it to determine commit ordering.

Ok, sounds sensible.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: B-Tree index builds, CLUSTER, and sortsupport
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Repeatable read and serializable transactions see data committed after tx start