From: Bruce Momjian <bruce@momjian.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: transction_timestamp() inside of procedures
Date: Wed, 26 Sep 2018 08:52:07 -0400
Message-ID: <20180926125207.GA10161@momjian.us> (raw)
In-Reply-To: <d2e75a46-a8af-e9f4-0106-609068e9c3f8@2ndquadrant.com>
References: <20180920234040.GC29981@momjian.us>
<20180921045536.GJ1338@paquier.xyz>
<20180921051206.bzfiew4nthmunpbj@alap3.anarazel.de>
<20180921053425.GM1338@paquier.xyz>
<20180921102822.GA22699@momjian.us>
<20180921223502.GA18319@momjian.us>
<d2e75a46-a8af-e9f4-0106-609068e9c3f8@2ndquadrant.com>
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 +
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bruce@momjian.us, peter.eisentraut@2ndquadrant.com, michael@paquier.xyz, andres@anarazel.de
Subject: Re: transction_timestamp() inside of procedures
In-Reply-To: <20180926125207.GA10161@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox