| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: transction_timestamp() inside of procedures |
| Date: | 2018-09-21 05:12:06 |
| Message-ID: | 20180921051206.bzfiew4nthmunpbj@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2018-09-21 13:55:36 +0900, Michael Paquier wrote:
> On Thu, Sep 20, 2018 at 07:40:40PM -0400, Bruce Momjian wrote:
> > This surprised me since I expected a new timestamp after commit. Is
> > this something we want to change or document? Are there other
> > per-transaction behaviors we should adjust?
>
> I don't quite follow your argument here. clock_timestamp is known to be
> volatile, while the two others are stable, so its value can change
> within a transaction.
Isn't the point that transaction_timestamp() does *not* currently change
its value, even though the transaction (although not the outermost
statement) has finished?
I think Bruce has quite the point here.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2018-09-21 05:17:07 | Re: Unclear error message |
| Previous Message | Michael Paquier | 2018-09-21 04:55:36 | Re: transction_timestamp() inside of procedures |