RE: Synchronizing slots from primary to standby
От | Zhijie Hou (Fujitsu) |
---|---|
Тема | RE: Synchronizing slots from primary to standby |
Дата | |
Msg-id | OS0PR01MB57162E9C2935E47A33D2A566944E2@OS0PR01MB5716.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Synchronizing slots from primary to standby (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Synchronizing slots from primary to standby
|
Список | pgsql-hackers |
On Wednesday, February 14, 2024 10:40 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Tue, Feb 13, 2024 at 9:25 PM Bertrand Drouvot > <bertranddrouvot.pg@gmail.com> wrote: > > > > On Tue, Feb 13, 2024 at 05:20:35PM +0530, Amit Kapila wrote: > > > On Tue, Feb 13, 2024 at 4:59 PM Bertrand Drouvot > > > <bertranddrouvot.pg@gmail.com> wrote: > > > > - 84% of the slotsync.c code is covered, the parts that are not > > > > are mainly related to "errors". > > > > > > > > Worth to try to extend the coverage? (I've in mind 731, 739, 766, > > > > 778, 786, 796, > > > > 808) > > > > > > > > > > All these additional line numbers mentioned by you are ERROR paths. > > > I think if we want we can easily cover most of those but I am not > > > sure if there is a benefit to cover each error path. > > > > Yeah, I think 731, 739 and one among the remaining ones mentioned > > up-thread should be enough, thoughts? > > > > I don't know how beneficial those selective ones would be but if I have to pick a > few among those then I would pick the ones at 731 and 808. The reason is that > 731 is related to cascading standby restriction which we may uplift in the future > and at that time one needs to be careful about the behavior, for 808 as well, in > the future, we may have a separate GUC for slot_db_name. These may not be > good enough reasons as to why we add tests for these ERROR cases but not for > others, however, if we have to randomly pick a few among all ERROR paths, > these seem better to me than others. Here is V87 patch that adds test for the suggested cases. Best Regards, Hou zj
Вложения
В списке pgsql-hackers по дате отправления: