Re: transction_timestamp() inside of procedures
От | Andres Freund |
---|---|
Тема | Re: transction_timestamp() inside of procedures |
Дата | |
Msg-id | E28DF5C1-E2EB-49D6-AC94-AC5FB99E58CF@anarazel.de обсуждение исходный текст |
Ответ на | Re: transction_timestamp() inside of procedures (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: transction_timestamp() inside of procedures
Re: transction_timestamp() inside of procedures |
Список | 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 по дате отправления: