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

From Andres Freund
Subject Re: transction_timestamp() inside of procedures
Date
Msg-id E28DF5C1-E2EB-49D6-AC94-AC5FB99E58CF@anarazel.de
Whole thread Raw
In response to Re: transction_timestamp() inside of procedures  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: transction_timestamp() inside of procedures
Re: transction_timestamp() inside of procedures
List pgsql-hackers
Hi,

On October 8, 2018 10:14:34 AM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>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);

Seems more reasonable from here.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: PostgreSQL 12, JIT defaults
Next
From: Pavel Stehule
Date:
Subject: Re: PostgreSQL 12, JIT defaults