> > 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
