Re: repeated decoding of prepared transactions
От | Markus Wanner |
---|---|
Тема | Re: repeated decoding of prepared transactions |
Дата | |
Msg-id | e7c6a5c6-f1a8-fb89-3080-e7f5ad0f35da@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: repeated decoding of prepared transactions (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: repeated decoding of prepared transactions
|
Список | pgsql-hackers |
Hello Amit, thanks for your very quick response. On 08.02.21 11:13, Amit Kapila wrote: > /* > * It is possible that this transaction is not decoded at prepare time > * either because by that time we didn't have a consistent snapshot or it > * was decoded earlier but we have restarted. We can't distinguish between > * those two cases so we send the prepare in both the cases and let > * downstream decide whether to process or skip it. We don't need to > * decode the xact for aborts if it is not done already. > */ The way I read the surrounding code, the only case a 2PC transaction does not get decoded a prepare time is if the transaction is empty. Or are you aware of any other situation that might currently happen? > (unless the server needs to be restarted due to some reason) Right, the repetition occurs only after a restart of the walsender in between a prepare and a commit prepared record. > That anyway is true without this work as well where restart_lsn can be > advanced on commits. We haven't changed anything in that regard. I did not mean to blame the patch, but merely try to understand some of the design decisions behind it. And as I just learned, even if we managed to avoid the repetition, a restarted walsender still needs to see prepared transactions as in-progress in its snapshots. So we cannot move forward the restart_lsn to after a prepare record (until the final commit or rollback is consumed). Best Regards Markus
В списке pgsql-hackers по дате отправления: