Re: transction_timestamp() inside of procedures - Mailing list pgsql-hackers

From Tom Lane
Subject Re: transction_timestamp() inside of procedures
Date
Msg-id 27414.1539018874@sss.pgh.pa.us
Whole thread Raw
In response to Re: transction_timestamp() inside of procedures  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: transction_timestamp() inside of procedures  (Andres Freund <andres@anarazel.de>)
Re: transction_timestamp() inside of procedures  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 02/10/2018 16:58, Andres Freund wrote:
>> It's a bit weird to make this decision based on these two timestamps
>> differing.  For one, it only indirectly seems to be guaranteed that
>> xactStartTimestamp is even set to anything here (to 0 by virtue of being
>> a global var).

> Maybe but it seems to be the simplest way without doing major surgery to
> all this code.

This patch doesn't apply over 07ee62ce9.  Also, I like the
timestamp-comparison approach even less than Andres does: I think it's
probably outright broken, especially since it treats the equality case
as license to advance xactStartTimestamp.

Surely there is some way that we can directly test whether we're inside a
procedure or not?  I think the logic should be basically

    if (!IsParallelWorker())
+   {
+       if (!InsideProcedure())
            xactStartTimestamp = stmtStartTimestamp;
+       else
+           xactStartTimestamp = GetCurrentTimestamp();
+   }
    else
       Assert(xactStartTimestamp != 0);


            regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: exclude tmp_check and tmp_install from pgindent
Next
From: Pavel Stehule
Date:
Subject: Re: PostgreSQL 12, JIT defaults