|From:||Bruce Momjian <bruce(at)momjian(dot)us>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>|
|Cc:||PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>|
|Subject:||Re: transction_timestamp() inside of procedures|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Tue, Oct 2, 2018 at 10:55:56AM +0200, Peter Eisentraut wrote:
> On 28/09/2018 09:35, Peter Eisentraut wrote:
> >> That's certainly a good argument. Note that if we implemented that the
> >> transaction timestamp is advanced inside procedures, that would also
> >> mean that the transaction timestamp as observed in pg_stat_activity
> >> would move during VACUUM, for example. That might or might not be
> >> desirable.
> > Attached is a rough implementation.
> > I'd be mildly in favor of doing this, but we have mentioned tradeoffs in
> > this thread.
> So do we want to do this or not?
I thought some more about this. I think there are a few issues:
1 Utility: since you can't use CALL in a transaction block, our
current code will always have transaction_timestamp() and
statement_timestamp() as identical in a procedure. Having
transaction_timestamp() advance on COMMIT gives users a new ability.
2 Surprise: What do people use transaction_timestamp() for and what
behavior would be most expected?
3 Other databases: How do other database systems handle this, and the
Based on 1 and 2, I suggest we change transaction_timestamp() to advance
on COMMIT in procedure, and document this. I have no idea on #3.
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
|Next Message||Amit Kapila||2018-10-02 14:18:09||Re: SerializeParamList vs machines with strict alignment|
|Previous Message||Joe Conway||2018-10-02 14:16:12||Re: Commit fest 2018-09|