On Fri, Mar 5, 2021 at 5:40 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.mu...@gmail.com> writes: > > On Fri, Mar 5, 2021 at 5:10 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Alternatively, maybe we can salvage the function's usefulness by making it > >> flush WAL before returning? > > > To make pg_xact_status()'s result reliable, don't you need to make > > pg_current_xact_id() flush? In other words, isn't it at the point > > that you *observe* the transaction that you have to make sure that > > this transaction ID won't be reused after crash recovery. Before > > that, it's simultaneously allocated and unallocated, like the cat. > > We need to be sure that the XID is written out to WAL before we > let the client see it, yeah. I've not looked to see exactly > where in the code would be the best place.
One idea would be for TransactionStateData's bool member didLogXid to become an LSN, initially invalid, that points one past the first record logged for this transaction, maintained by MarkCurrentTransactionIdLoggedIfAny(). Then, pg_current_xact_id() (and any similar xid-reporting function that we deem to be an officially sanctioned way for a client to "observe" xids) could check if it's valid yet; if not, it could go ahead and log something containing the xid to make it valid. Then it could flush the log up to that LSN.
