Re: issue with synchronized_standby_slots
| От | Fujii Masao | 
|---|---|
| Тема | Re: issue with synchronized_standby_slots | 
| Дата | |
| Msg-id | CAHGQGwFYkFpAtobRGuYwvJmmvjUgPpuksxCWx5A2FLMkwfodkw@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: issue with synchronized_standby_slots (Amit Kapila <amit.kapila16@gmail.com>) | 
| Ответы | 
                	
            		Re: issue with synchronized_standby_slots
            		
            		 | 
		
| Список | pgsql-hackers | 
On Thu, Oct 23, 2025 at 8:28 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > +-- Parallel worker does not throw error during startup. > +SET min_parallel_table_scan_size TO 0; > +SET max_parallel_workers_per_gather TO 2; > +SET parallel_setup_cost TO 0; > +SET parallel_tuple_cost TO 0; > +CREATE TABLE t1(a int); > +INSERT INTO t1 VALUES(1), (2), (3), (4); > +SELECT count(*) FROM t1; > > Isn't it better to reset these parameters after the test? I think the intention of this test case is to verify that the issue seen in HEAD no longer occurs with the patch applied. So in HEAD this test procedure needs to be able to reproduce the problem with synchronized_standby_slots and parallel workers, but does it actually do? I'm afraid additional steps are needed. Also, I wonder if it's really worth doing this test after the fix, since it seems a special case. +-- Cannot set synchronized_standby_slots to a invalid slot name. +ALTER SYSTEM SET synchronized_standby_slots='invalid*'; Typo: "a invalid" should be "an invalid" Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: