RE: A failure in t/038_save_logical_slots_shutdown.pl
От | Hayato Kuroda (Fujitsu) |
---|---|
Тема | RE: A failure in t/038_save_logical_slots_shutdown.pl |
Дата | |
Msg-id | TY3PR01MB9889E69C5D06A56E0AFDE0E4F5732@TY3PR01MB9889.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: A failure in t/038_save_logical_slots_shutdown.pl (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: A failure in t/038_save_logical_slots_shutdown.pl
|
Список | pgsql-hackers |
Dear Amit, Bharath, > This is a more strict check because it is possible that even if the > latest confirmed_flush location is not persisted there is no > meaningful decodable WAL between whatever the last confirmed_flush > location saved on disk and the shutdown_checkpoint record. > Kuroda-San/Vignesh, do you have any suggestion on this one? I think it should be as testcase explicitly. There are two reasons: * e0b2eed is a commit for backend codes, so it should be tested by src/test/* files. Each src/bin/XXX/*.pl files should test only their executable. * Assuming that the feature would be broken. In this case 003_logical_slots.pl would fail, but we do not have a way to recognize on the build farm. 038_save_logical_slots_shutdown.pl helps to distinguish the case. Based on that, I think it is OK to add advance_wal() and comments, like Bharath's patch. Best Regards, Hayato Kuroda FUJITSU LIMITED
В списке pgsql-hackers по дате отправления: