Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps
От | Heikki Linnakangas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps |
Дата | |
Msg-id | 54A1278F.8070608@vmware.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps (Petr Jelinek <petr@2ndquadrant.com>) |
Ответы |
Re: [COMMITTERS] pgsql: Keep track of transaction commit
timestamps
|
Список | pgsql-hackers |
On 12/19/2014 11:30 AM, Petr Jelinek wrote: > as promised I am sending code-comment patch that explains the use of > commit timestamps + nodeid C api for the conflict resolution, comments > welcome. That's a little bit better, but I have to say I'm still not impressed. There are so many implicit assumptions in the system. The first assumption is that a 32-bit node id is sufficient. I'm sure it is for many replication systems, but might not be for all. Then there's the assumption that the node id should be "sticky", i.e. it's set for the whole session. Again, I'm sure that's useful for many systems, but I could just as easily imagine that you'd want it to reset after every commit. To be honest, I think this patch should be reverted. Instead, we should design a system where extensions can define their own SLRUs to store additional per-transaction information. That way, each extension can have as much space per transaction as needed, and support functions that make most sense with the information. Commit timestamp tracking would be one such extension, and for this node ID stuff, you could have another one (or include it in the replication extension). - Heikki
В списке pgsql-hackers по дате отправления: