Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps

On 29/12/14 11:16, Andres Freund wrote:
> On 2014-12-29 12:06:07 +0200, Heikki Linnakangas wrote:
>> 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.
>
> Seriously? Are we going to build facilities for replication systems with
> that many nodes? It seems absolutely unrealistic that a) somebody does
> this b) that we'll blindly meet the demands of such a super hypothetical
> scenario.
>

+1, Honestly, if somebody will ever have setup with more nodes than what
fits into 32bits they will run into bigger problems than nodeid being
too small.

>> 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.
>
> It's trivial to add that/reset it manually. So what?

Yes you can reset in the extension after commit, or you can actually
override both commit timestamp and nodeid after commit if you so wish.

>
>> 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).
>
> If somebody wants that they should develop it. But given that we, based
> on previous discussions, don't want to run user defined code in the
> relevant phase during transaction commit *and* replay I don't think it'd
> be all that easy to do it fast and flexible.
>

Right, I would love to have custom SLRUs but I don't see it happening
given those two restrictions, otherwise I would write the CommitTs patch
that way in the first place...

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