"Peter J. Holzer" <hjp-pgsql@xxxxxx> writes: > Again, I'm not arguing for such a change, but I'm wondering if recording > transaction_timestamp just after the snapshot might be a safe change or > whether that might break some assumption that programmers can currently > make. As I mentioned upthread, we currently promise that xact_start matches the query_start of the transaction's first statement. (I'm not sure how well that's documented, but the code goes out of its way to make it so, so somebody thought it was important.) Another issue with redefining things like that is that presumably, for a session that has issued BEGIN but not yet taken a snapshot, xact_start would have to read as NULL, misleadingly implying that the session doesn't have an open transaction. Lastly, wouldn't postponing the collection of the timestamp like that break the very property you want to promise, by making other transactions' timestamps nontrivially later than they are now? I think if we wanted to do something here, it'd make more sense to keep xact_start as it stands and introduce a new variable snapshot_timestamp or something like that. Then maybe we could have some guarantees about what you get when comparing other sessions' xact_start to your own snapshot_timestamp. But I'm not convinced we can really guarantee anything without reading the snapshot_timestamp within the snapshot-collecting critical section, and I'm not for that. regards, tom lane
