| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com> |
| Cc: | Ajin Cherian <itsajin(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, simon(dot)riggs(at)enterprisedb(dot)com, Andres Freund <andres(at)anarazel(dot)de>, Petr Jelinek <petr(dot)jelinek(at)enterprisedb(dot)com> |
| Subject: | Re: repeated decoding of prepared transactions |
| Date: | 2021-02-20 03:38:03 |
| Message-ID: | CAA4eK1K=0ATht4bDU0vZRiiM03KMApWw0sTo+-WLtXutboZqnQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Feb 19, 2021 at 8:23 PM Markus Wanner
<markus(dot)wanner(at)enterprisedb(dot)com> wrote:
>
> With that line of thinking, the point in time (or in WAL) of the COMMIT
> PREPARED does not matter at all to reason about the decoding of the
> PREPARE operation. Instead, there are only exactly two cases to consider:
>
> a) the PREPARE happened before the start_decoding_at LSN and must not be
> decoded. (But the effects of the PREPARE must then be included in the
> initial synchronization. If that's not supported, the output plugin
> should not enable two-phase commit.)
>
I see a problem with this assumption. During the initial
synchronization, this transaction won't be visible to snapshot and we
won't copy it. Then later if we won't decode and send it then the
replica will be out of sync. Such a problem won't happen with Ajin's
patch.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2021-02-20 03:54:59 | Re: A reloption for partitioned tables - parallel_workers |
| Previous Message | Justin Pryzby | 2021-02-20 02:40:11 | Re: progress reporting for partitioned REINDEX |