Re: tracking commit timestamps

On 04/11/14 09:25, Michael Paquier wrote:
> On Tue, Nov 4, 2014 at 5:05 PM, Andres Freund <andres(at)2ndquadrant(dot)com
> <mailto:andres(at)2ndquadrant(dot)com>> wrote:
>
> On 2014-11-02 19:27:25 +0100, Petr Jelinek wrote:
> > Well, Michael has point that the extradata is pretty much useless currently,
> > perhaps it would help to add the interface to set extradata?
>
> Only accessible via C and useless aren't the same thing. But sure, add
> it.
>
> 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.

The issue as I see it is that both of those features are closely related
and just one without the other has very limited use. What I learned from
working on UDR is that for conflict handling, I was actually missing the
extradata more than the timestamp itself - in other words I have
extension for 9.4 where I have use for this API already, so the argument
about dead code or forks or whatever does not really hold.

The other problem is that if we add extradata later we will either break
upgrade-ability of will have to write essentially same code again which
will store just the extradata instead of the timestamp, I don't really
like either of those options to be honest.

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