From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeremy Finzel <finzelj(at)gmail(dot)com> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Automated way to find actual COMMIT LSN of subxact LSN |
Date: | 2019-03-21 14:26:24 |
Message-ID: | 10776.1553178384@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeremy Finzel <finzelj(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2019-03-21 14:27:30 | Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits |
Previous Message | Imai Yoshikazu | 2019-03-21 14:10:59 | Re: speeding up planning with partitions |