| From: | "Daniel Verite" <daniel(at)manitou-mail(dot)org> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Bruce Momjian" <bruce(at)momjian(dot)us>,"Peter Eisentraut" <peter(dot)eisentraut(at)2ndquadrant(dot)com>,"Michael Paquier" <michael(at)paquier(dot)xyz>,"Andres Freund" <andres(at)anarazel(dot)de>,"PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: transction_timestamp() inside of procedures |
| Date: | 2018-09-26 19:23:58 |
| Message-ID: | 426715fa-0dd7-4826-b079-1426ca8e6f12@manitou-mail.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> I agree that it would be surprising for transaction timestamp to be newer
> than statement timestamp.
To me it's more surprising to start a new transaction and having
transaction_timestamp() still pointing at the start of a previous
transaction.
This feels like a side-effect of being spawned by a procedure,
and an exception to what transaction_timestamp() normally means
or meant until now.
OTOH transaction_timestamp() being possibly newer than
statement_timestamp() seems like a normal consequence of
transactions being created intra-statement.
+1 for transaction_timestamp() and pg_stat_activity being updated
to follow intra-procedure transactions.
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-09-26 19:35:25 | Re: pgsql: Remove absolete function TupleDescGetSlot(). |
| Previous Message | Andres Freund | 2018-09-26 19:13:12 | Re: Allowing printf("%m") only where it actually works |