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  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "iwata.aya@fujitsu.com"
Дата:
Сообщение: RE: libpq debug log
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Made ecpg compatibility mode and run-time behaviour options case insensitive