| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Ajin Cherian <itsajin(at)gmail(dot)com> |
| Subject: | Re: repeated decoding of prepared transactions |
| Date: | 2021-02-11 19:40:08 |
| Message-ID: | CA+Tgmoax+qiNmicwg1ZK_sRM3+RPUvHRS8PJ3TaeR++J-Chn9g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 11, 2021 at 5:37 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> to explain the exact case to you which is not very apparent. The basic
> idea is that we ship/replay all transactions where commit happens
> after the snapshot has a consistent state (SNAPBUILD_CONSISTENT), see
> atop snapbuild.c for details. Now, for transactions where prepare is
> before snapshot state SNAPBUILD_CONSISTENT and commit prepared is
> after SNAPBUILD_CONSISTENT, we need to send the entire transaction
> including prepare at the commit time.
This might be a dumb question, but: why?
Is this because the effects of the prepared transaction might
otherwise be included neither in the initial synchronization of the
data nor in any subsequently decoded transaction, thus leaving the
replica out of sync?
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-02-11 19:50:13 | Re: Tightening up allowed custom GUC names |
| Previous Message | Darafei Komяpa Praliaskouski | 2021-02-11 18:59:46 | Re: Tightening up allowed custom GUC names |