Re: Automated way to find actual COMMIT LSN of subxact LSN

>
> I find this to be unactionably vague. What does it mean to claim "an
> LSN is visible"? An LSN might not even point to a WAL record, or it
> might point to one that has nontransactional effects. Moreover, any
> behavior of this sort would destroy what I regard as a bedrock property
> of recover-to-LSN, which is that there's a well defined, guaranteed-finite
> stopping point. (A property that recover-to-XID lacks, since the
> specified XID might've crashed without recording either commit or abort.)
>

I mentioned that my specific use case is that I am picking out an LSN or
XID within the context of logical decoding. So I don't think that's vague,
but let me clarify. When using the peek_changes or get_changes functions,
they only show a particular update to a particular row, with a
corresponding LSN and transaction ID. That's what I see using both
test_decoding and pglogical_output, both of which I have used in this way.
In that context at least, all LSNs and XIDs point to committed WAL data
only.

> I think what you ought to be doing is digging the xmin out of the inserted
> tuple you're concerned with and then doing recover-to-XID. There's
> definitely room for us to make it easier if the XID is a subxact rather
> than a main xact. But I think identifying the target XID is your job
> not the job of the recovery-stop-point mechanism.
>

I'm open to that, but how will it help if I can't guarantee that the tuple
wasn't updated again after the original insert/update of interest?

Thank you,
Jeremy