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

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-20 16:43:11
Message-ID: 10496.1553100191@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:
> A related problem kind of demonstrates the same odd behavior. If you put
> in recovery_target_xid to a subtransaction_id, it just skips it and
> continues recovering, which really seems to be undesirable behavior. It
> would be nice if that also could roll up to the next valid actual commit
> transaction.

It would seem like what you're asking for is to continue until the commit
of the parent transaction, not just the next commit after the subcommit.
Otherwise (if that's an unrelated xact) the subxact would still not be
committed, so that you might as well have stopped short of it.

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.

I don't recall this for sure, but doesn't a parent xact's commit record
include all subxact XIDs? If so, the implementation would just require
searching the subxacts as well as the main XID for a match to
recovery_target_xid.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2019-03-20 16:46:32 Re: Offline enabling/disabling of data checksums
Previous Message Julien Rouhaud 2019-03-20 16:20:11 Re: Sparse bit set data structure