Re: Single transaction in the tablesync worker?
От | Peter Smith |
---|---|
Тема | Re: Single transaction in the tablesync worker? |
Дата | |
Msg-id | CAHut+Pu7B2g=5WS3dhScqJMHBH8-HaoKLrtG0Q6cUMxDG5CLyw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Single transaction in the tablesync worker? (Peter Smith <smithpb2250@gmail.com>) |
Ответы |
Re: Single transaction in the tablesync worker?
Re: Single transaction in the tablesync worker? |
Список | pgsql-hackers |
On Mon, Feb 8, 2021 at 11:42 AM Peter Smith <smithpb2250@gmail.com> wrote: > > On Sun, Feb 7, 2021 at 2:38 PM Peter Smith <smithpb2250@gmail.com> wrote: > > > > On Sat, Feb 6, 2021 at 2:10 AM Petr Jelinek > > <petr.jelinek@enterprisedb.com> wrote: > > > > > > Hi, > > > > > > Some minor comments about code: > > > > > > > + else if (res->status == WALRCV_ERROR && missing_ok) > > > > + { > > > > + /* WARNING. Error, but missing_ok = true. */ > > > > + ereport(WARNING, > > > > > > I wonder if we need to add error code to the WalRcvExecResult and check > > > for the appropriate ones here. Because this can for example return error > > > because of timeout, not because slot is missing. Not sure if it matters > > > for current callers though (but then maybe don't call the param > > > missign_ok?). > > > > You are right. The way we are using this function has evolved beyond > > the original intention. > > Probably renaming the param to something like "error_ok" would be more > > appropriate now. > > > > PSA a patch (apply on top of V28) to change the misleading param name. > PSA an alternative patch. This one adds a new member to WalRcvExecResult and so is able to detect the "slot does not exist" error. This patch also applies on top of V28, if you want it. ------ Kind Regards, Peter Smith. Fujitsu Australia
Вложения
В списке pgsql-hackers по дате отправления: