Re: tracking commit timestamps

On 2014-11-01 22:00:40 +0900, Michael Paquier wrote:
> On Sat, Nov 1, 2014 at 1:45 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)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.

> - The API to get the commit timestamp is not that user-friendly, and I
> think it could really be improved, to something like that for example:
> pg_get_commit_timestamp(from_xact xid, number_of_xacts int);

What'd be the point of this?

Greetings,

Andres Freund

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