| From: | Ajin Cherian <itsajin(at)gmail(dot)com> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)enterprisedb(dot)com>, Petr Jelinek <petr(dot)jelinek(at)enterprisedb(dot)com> |
| Subject: | Re: repeated decoding of prepared transactions |
| Date: | 2021-02-09 06:27:29 |
| Message-ID: | CAFPTHDZLcjmhwg83SoeByi9JgRtydFu9ky50R_R81CW-1upfGg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Feb 9, 2021 at 4:59 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> Can you please provide steps which can lead to this situation? If
> there is an earlier discussion which has example scenarios, please
> point us to the relevant thread.
>
> If we are not sending PREPARED transactions that's fine, but sending
> the same prepared transaction as many times as the WAL sender is
> restarted between sending prepare and commit prepared is a waste of
> network bandwidth. The wastage is proportional to the amount of
> changes in the transaction and number of such transactions themselves.
> Also this will cause performance degradation. So if we can avoid
> resending prepared transactions twice that will help.
One of this scenario is explained in the test case in
postgres/contrib/test_decoding/specs/twophase_snapshot.spec
regards,
Ajin Cherian
Fujitsu Australia
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2021-02-09 06:32:00 | Re: Single transaction in the tablesync worker? |
| Previous Message | Kyotaro Horiguchi | 2021-02-09 06:05:43 | Re: Is Recovery actually paused? |