Jeremy Finzel <finzelj@gmail.com> writes:
>> I'd be in favor of that for recovery_target_xid, but I'm not at all
>> convinced about changing the behavior for a target LSN. The fact that
>> the target is a subcommit seems irrelevant when you specify by LSN.
> For this use case, my goal is simply to be able to recover the the point
> immediately after a particular decoded log line is visible, without
> necessarily having to find out the final parent transaction id.
> Given this, I am open to different implementations but I would like to
> either be able to specify an LSN or transaction ID, and have a feature that
> allows the recovery target to roll forward just until it is visible, even
> if the LSN or transaction ID is not the actual commit of the parent
> transaction.
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 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.
regards, tom lane
