Re: tracking commit timestamps
От | Alvaro Herrera |
---|---|
Тема | Re: tracking commit timestamps |
Дата | |
Msg-id | 20141103203648.GU1791@alvin.alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: tracking commit timestamps (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: tracking commit timestamps
|
Список | pgsql-hackers |
Jim Nasby wrote: > On 11/1/14, 8:41 AM, Petr Jelinek wrote: > >Well this is not BDR specific thing, the idea is that with logical replication, commit timestamp is not enough for conflicthandling, you also need to have additional info in order to identify some types of conflicts conflicts (local updatevs remote update for example). So the extradata field was meant as something that could be used to add the additionalinfo to the xid. > > Related to this... is there any way to deal with 2 transactions that commit in the same microsecond? It seems silly totry and handle that for every commit since it should be quite rare, but perhaps we could store the LSN as extradata ifwe detect a conflict? Well, two things. One, LSN is 8 bytes and extradata (at least in this patch when I last saw it) is only 4 bytes. But secondly and more important is that detecting a conflict is done in node B *after* node A has recorded the transaction's commit time; there is no way to know at commit time that there is going to be a conflict caused by that transaction in the future. (If there was a way to tell, you could just as well not commit the transaction in the first place.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: