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
