On 2014-11-04 10:01:00 -0300, Alvaro Herrera wrote: > Michael Paquier wrote: > > > I'm still on a -1 for that. You mentioned that there is perhaps no reason > > to delay a decision on this matter, but IMO there is no reason to rush > > either in doing something we may regret. And I am not the only one on this > > thread expressing concern about this extra data thingy. > > > > If this extra data field is going to be used to identify from which node a > > commit comes from, then it is another feature than what is written on the > > subject of this thread. In this case let's discuss it in the thread > > dedicated to replication identifiers, or come up with an extra patch once > > the feature for commit timestamps is done. > > Introducing the extra data field in a later patch would mean an on-disk > representation change, i.e. pg_upgrade trouble.
It's also simply not necessarily related to replication identifiers. This is useful whether replication identifiers make it in or not. It allows to implement something like replication identifiers outside of core (albeit with a hefty overhead in OLTP workloads). Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
