Re: issue with synchronized_standby_slots - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: issue with synchronized_standby_slots
Date
Msg-id CAA4eK1LuYdDwW38Tv3mX=XxULsRnjBvROMM6FL1oY0YDF1QgJg@mail.gmail.com
Whole thread Raw
In response to Re: issue with synchronized_standby_slots  (Shlok Kyal <shlok.kyal.oss@gmail.com>)
Responses Re: issue with synchronized_standby_slots
List pgsql-hackers
On Thu, Oct 23, 2025 at 2:58 PM Shlok Kyal <shlok.kyal.oss@gmail.com> wrote:
>
> On Thu, 23 Oct 2025 at 13:45, Hayato Kuroda (Fujitsu)
> <kuroda.hayato@fujitsu.com> wrote:
> >
> > 2.
> > Also, test for PG18 should not have the case which rejects the reserved name.
> >

Why to have that even for HEAD and PG18?

> > 3.
> > ```
> > -- Parallel worker does not throw error during startup.
> > SET min_parallel_table_scan_size TO 0;
> > SET parallel_setup_cost TO 0;
> > SET parallel_tuple_cost TO 0;
> > ```
> >
> > According to contrib/pg_stat_statements/sql/parallel.sql, max_parallel_workers_per_gather
> > should be also set. There is a possiblity that `make installcheck` is used and
> > it has max_parallel_workers_per_gather=0.
> >

+-- 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?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Logical Replication of sequences
Next
From: Arseniy Mukhin
Date:
Subject: Re: amcheck: support for GiST