Re: transction_timestamp() inside of procedures
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-09-26T12:52:07Z
Lists: pgsql-hackers
On Wed, Sep 26, 2018 at 02:38:25PM +0200, Peter Eisentraut wrote: > On 22/09/2018 00:35, Bruce Momjian wrote: > > I have always thought of clock/statement/transation as decreasing levels > > of time precision, and it might be odd to change that. I don't think we > > want to change the behavior of statement_timestamp() in procedures, so > > that kind of requires us not to change transaction_timestamp() inside of > > procedures. > > > > However, no change in behavior causes the problem that if you have a > > transaction block using transaction_timestamp() or CURRENT_TIMESTAMP, > > and you move it into a procedure, the behavior of those functions will > > change, but this was always true of moving statement_timestamp() into a > > function, and I have never heard a complaint about that. > > Right. Statement timestamp actually means the timestamp of the > top-level statement, because it's set where the protocol interaction > happens. The transaction timestamp is implemented as the statement > timestamp when the transaction starts, but for intra-procedural > transactions, the statement timestamp does not advance, so the > transaction timestamp doesn't change. > > Note that this also affects the xact_start column in pg_stat_activity. > > We could certainly address this by adding three or four or five new > timestamps that cover all these varieties. But perhaps it's worth > asking what these timestamps are useful for and which ones we really need. Frankly, we might be fine with just documenting it and see if anyone complains. I think the top-level statement part is obvious, but I am not sure the top-level transaction part is. This is because it is clear the top-level statement causes all the lower statements underneath it, but the top-level transaction doesn't control all the transactions under it in the same way. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Commits
-
Advance transaction timestamp for intra-procedure transactions.
- 82ff0cc91d98 12.0 landed
- 1145c26b749a 11.0 landed