On 01/11/14 18:44, Andres Freund wrote:
On 2014-11-01 22:00:40 +0900, Michael Paquier wrote:
On Sat, Nov 1, 2014 at 1:45 PM, Michael Paquier <michael.paqu...@gmail.com>
wrote:
I am still planning to do more extensive tests, and study a bit more
committs.c (with even more comments) as it is the core part of the feature.
More comments:
- Heikki already mentioned it, but after reading the code I see little
point in having the extra field implementing like that in core for many
reasons even if it is *just* 4 bytes:
1) It is untested and actually there is no direct use for it in core.
Meh. The whole feature is only there for extensions, not core.
2) Pushing code that we know as dead is no good, that's a feature more or
less defined as maybe-useful-but-we-are-not-sure-yet-what-to-do-with-it.
Uh. It's not more/less dead than the whole of committs.
3) If you're going to re-use this API in BDR, which is a fork of Postgres.
You'd better complete this API in BDR by yourself and not bother core with
that.
I think that's a fundamentally wrong position. The only reason BDR isn't
purely stock postgres is that some features couldn't sanely be made work
without patches. I *hate* the fact that we had to do so. And I really
hope that we don't need any of the patches we have when building against
9.5.
So, now you might argue that the additional data is useless. But I think
that's just not thought far enough. If you think about it, in which
scenarios do you want to map xids to the commit timestamp? Primarily
that's going to be replication, right? One of the most obvious usecases
is allowing to detect/analyze/resolve conflicts in a multimaster setup,
right? To make sensible decisisons you'll often want to have more
information about the involved transactions. Makes sense so far?
Now, you might argue that could just be done with some table
transaction_metadata(xid DEFAULT txid_current(), meta, data). But that
has *significant* disadvantages: For one, it'll not work correctly once
subtransactions are used. Not good. For another it has about a
magnitude higher overhead than the committs way.
And it's not like the the extra field is in any way bdr specific - even
if you actually want to store much more information about the
transaction than just the origin (which is what bdr does), you can use
it to correctly solve the subtransaction problem and refer to some
transaction metadata table.
Well, Michael has point that the extradata is pretty much useless
currently, perhaps it would help to add the interface to set extradata?
--
Petr Jelinek 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
