| From: | Ajin Cherian <itsajin(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Single transaction in the tablesync worker? |
| Date: | 2021-02-04 04:24:51 |
| Message-ID: | CAFPTHDbN1z0c_ZD9P2-TD_MKf7xb2Ogq+fhFKOYUtDwcO_3WUA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Feb 3, 2021 at 11:38 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> Thanks for the report. The problem here was that the error occurred
> when we were trying to copy the large data. Now, before fetching the
> entire data we issued a rollback that led to this problem. I think the
> alternative here could be to first fetch the entire data when the
> error occurred then issue the following commands. Instead, I have
> modified the patch to perform 'drop_replication_slot' in the beginning
> if the relstate is datasync. Do let me know if you can think of a
> better way to fix this?
I have verified that the problem is not seen after this patch. I also
agree with the approach taken for the fix,
regards,
Ajin Cherian
Fujitsu Australia
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2021-02-04 04:27:34 | Re: pg_replication_origin_drop API potential race condition |
| Previous Message | Masahiko Sawada | 2021-02-04 04:17:37 | Re: New IndexAM API controlling index vacuum strategies |