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

Поиск
Список
Период
Сортировка
Искать
От
Jeremy Finzel
Тема
Re: Automated way to find actual COMMIT LSN of subxact LSN
Дата
Msg-id
CAMa1XUjvvOQRpAWiAn5DBLZph+coX0JdJgjjMRUfitbosZzVJA@mail.gmail.com
Ответ на
Список
Дерево обсуждения
Automated way to find actual COMMIT LSN of subxact LSN Jeremy Finzel <finzelj@gmail.com>
Re: Automated way to find actual COMMIT LSN of subxact LSN Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Re: Automated way to find actual COMMIT LSN of subxact LSN Jeremy Finzel <finzelj@gmail.com>
Re: Automated way to find actual COMMIT LSN of subxact LSN Tom Lane <tgl@sss.pgh.pa.us>
Re: Automated way to find actual COMMIT LSN of subxact LSN Jeremy Finzel <finzelj@gmail.com>
Re: Automated way to find actual COMMIT LSN of subxact LSN Tom Lane <tgl@sss.pgh.pa.us>
Re: Automated way to find actual COMMIT LSN of subxact LSN Jeremy Finzel <finzelj@gmail.com>
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
В списке pgsql-hackers по дате отправления
От: Tatsuo Ishii
Дата:
От: Fred .Flintstone
Дата:
FAQ