RE: Optionally automatically disable logical replication subscriptions on error
От | osumi.takamichi@fujitsu.com |
---|---|
Тема | RE: Optionally automatically disable logical replication subscriptions on error |
Дата | |
Msg-id | TYCPR01MB8373AE0ECFB4AAB1CC2FBEF8ED3E9@TYCPR01MB8373.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Optionally automatically disable logical replication subscriptions on error (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | pgsql-hackers |
On Thursday, February 24, 2022 4:50 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > On Tue, Feb 22, 2022 at 3:03 PM Peter Smith <smithpb2250@gmail.com> > wrote: > > > > ~~~ > > > > 1. worker.c - comment > > > > + subform = (Form_pg_subscription) GETSTRUCT(tup); > > + > > + /* > > + * We would not be here unless this subscription's disableonerr field > > + was > > + * true, but check whether that field has changed in the interim. > > + */ > > + if (!subform->subdisableonerr) > > + { > > + heap_freetuple(tup); > > + table_close(rel, RowExclusiveLock); > > + CommitTransactionCommand(); > > + return false; > > + } > > > > I felt that comment belongs above the subform assignment because that > > is the only reason we are getting the subform again. > > IIUC if we return false here, the same error will be emitted twice. > And I'm not sure this check is really necessary. It would work only when the > subdisableonerr is set to false concurrently, but doesn't work for the opposite > caces. I think we can check > MySubscription->disableonerr and then just update the tuple. Addressed. I followed your advice and deleted the check. Kindly have a look at v22 shared in [1]. [1] - https://www.postgresql.org/message-id/TYCPR01MB8373D9B26F988307B0D3FE20ED3E9%40TYCPR01MB8373.jpnprd01.prod.outlook.com Best Regards, Takamichi Osumi
В списке pgsql-hackers по дате отправления: