Re: Single transaction in the tablesync worker?

From: Petr Jelinek <petr(dot)jelinek(at)enterprisedb(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Peter Smith <smithpb2250(at)gmail(dot)com>, Ajin Cherian <itsajin(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-11 08:21:28
Message-ID: 73082F3E-0E78-4754-BC27-A8410125736F@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10 Feb 2021, at 06:32, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Feb 10, 2021 at 7:41 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>>
>> On Tue, Feb 9, 2021 at 10:38 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>>>
>>
>> PSA v2 of this WalRcvExceResult patch (it is same as v1 but includes
>> some PG doc updates).
>> This applies OK on top of v30 of the main patch.
>>
>
> Thanks, I have integrated these changes into the main patch and
> additionally made some changes to comments and docs. I have also fixed
> the function name inconsistency issue you reported and ran pgindent.

One thing:

> + else if (res->status == WALRCV_ERROR &&
> + missing_ok &&
> + res->sqlstate == ERRCODE_UNDEFINED_OBJECT)
> + {
> + /* WARNING. Error, but missing_ok = true. */
> + ereport(WARNING,
> (errmsg("could not drop the replication slot \"%s\" on publisher",
> slotname),
> errdetail("The error was: %s", res->err)));

Hmm, why is this WARNING, we mostly call it with missing_ok = true when the slot is not expected to be there, so it does not seem correct to report it as warning?

--
Petr

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-02-11 09:42:07 Re: Single transaction in the tablesync worker?
Previous Message Peter Smith 2021-02-11 08:10:19 Re: [HACKERS] logical decoding of two-phase transactions