Re: 011_crash_recovery.pl intermittently fails

On Fri, Mar 5, 2021 at 5:40 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > On Fri, Mar 5, 2021 at 5:10 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.