"Peter J. Holzer" <hjp-pg...@hjp.at> 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
