pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
To: 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 14:38:25 +0200
Message-ID: <d2e75a46-a8af-e9f4-0106-609068e9c3f8@2ndquadrant.com> (raw)
In-Reply-To: <20180921223502.GA18319@momjian.us>
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>

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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




view thread (32+ messages)  latest in thread

Message-ID: <d2e75a46-a8af-e9f4-0106-609068e9c3f8@2ndquadrant.com>
Permalink:  ../d2e75a46-a8af-e9f4-0106-609068e9c3f8@2ndquadrant.com/
Also on:    postgresql.org/message-id/d2e75a46-a8af-e9f4-0106-609068e9c3f8@2ndquadrant.com

 · 

reply

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: peter.eisentraut@2ndquadrant.com, bruce@momjian.us, michael@paquier.xyz, andres@anarazel.de
  Subject: Re: transction_timestamp() inside of procedures
  In-Reply-To: <d2e75a46-a8af-e9f4-0106-609068e9c3f8@2ndquadrant.com>

* 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