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

From: Jeremy Finzel <finzelj(at)gmail(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: 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 15:27:19
Message-ID: CAMa1XUjvvOQRpAWiAn5DBLZph+coX0JdJgjjMRUfitbosZzVJA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> If recovery_target_inclusive were able to take the third value
> "xact", is it exactly what you want?
>
> And is it acceptable?
>

Yes, that would be exactly what I would want. It would work to have a 3rd
value for recovery_target_inclusive, although perhaps it's debatable that
instead, it should actually be the default behavior to roll any LSN with
recovery_target_inclusive = true until it is actually visible? If I say I
want to "include" an LSN in my recovery target, it doesn't make much sense
if that just won't be visible unless it's an actual commit LSN, so in fact
the recovery point does not include the LSN.

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.

Thanks!
Jeremy

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fred .Flintstone 2019-03-20 15:30:33 Re: PostgreSQL pollutes the file system
Previous Message Haoran Yu 2019-03-20 15:26:28 Re: Interested in GSoC projects on pgAdmin 4