On Thu, Jun 27, 2019 at 11:38 PM Heikki Linnakangas <hlinn...@iki.fi> wrote: > * I moved the logic to extend a 32-bit XID to 64-bits to a new helper > function in varsup.c.
I'm a bit uneasy about making this into a generally available function for reuse. I think we should instead come up with a very small number of sources of fxids that known to be free of races because of some well explained interlocking. For example, I believe it is safe to convert an xid obtained from a WAL record during recovery, because (for now) recovery is a single thread of execution and the next fxid can't advance underneath you. So I think XLogRecGetFullXid(XLogReaderState *record)[1] as I'm about to propose in another thread (though I've forgotten who wrote it, maybe Andres, Amit or me, but if it wasn't me then it's exactly what I would have written) is a safe blessed source of fxids. The rationale for writing this function instead of an earlier code that looked much like your proposed helper function, during EDB-internal review of zheap stuff, was this: if we provide a general purpose xid->fxid facility, it's virtually guaranteed that someone will eventually use it to shoot footwards, by acquiring an xid from somewhere, and then some arbitrary time later extending it to a fxid when no interlocking guarantees that the later conversion has the correct epoch. I'd like to figure out how to maintain full versions of the procarray.c-managed xid horizons, without widening the shared memory representation. I was planning to think harder about for 13. Obviously that doesn't help you now. So I'm wondering if you should just open-code this for now, and put in a comment about why it's safe and a note that there'll hopefully be a fxid horizon available in a later release? [1] https://github.com/EnterpriseDB/zheap/commit/1203c2fa49f5f872f42ea4a02ccba2b191c45f32 -- Thomas Munro https://enterprisedb.com
