Re: Bypassing cursors in postgres_fdw to enable parallel plans

At 2026-07-03 20:51:12，"Rafia Sabih" <rafia.pghackers@gmail.com>  wrote  ：
>
> No, but I don't understand why you think they can be different in the
> current implementation.
> Currently, as per init_scan fsstate->conn_state->active_scan = fsstate, and
> it is never reassigned or anything.
> So they cannot have different conn_state.
> Am I missing something?
> 


This is the reproduction procedure for the crash caused by clearing active_scan that I mentioned last week.


Data preparation:
  CREATE TABLE local_big (id int, val text);
  CREATE TABLE local_big2 (id int, val text);
  INSERT INTO local_big SELECT i, 'val_' || i FROM generate_series(1, 300000) i;
  INSERT INTO local_big2 SELECT i, 'val_' || i FROM generate_series(1, 300000) i;
  CREATE SERVER test_srv FOREIGN DATA WRAPPER postgres_fdw
      OPTIONS (host 'localhost', port '55436', dbname 'test_bug2');
  CREATE USER MAPPING FOR CURRENT_USER SERVER test_srv;
  CREATE FOREIGN TABLE ft_big (id int, val text)
      SERVER test_srv
      OPTIONS (schema_name 'public', table_name 'local_big',
               streaming_fetch 'true', fetch_size '1');
  CREATE FOREIGN TABLE ft_small (id int, val text)
      SERVER test_srv
      OPTIONS (schema_name 'public', table_name 'local_big2',
               streaming_fetch 'true', fetch_size '1');


session-1


  DROP TABLE IF EXISTS bug2_pid;
  CREATE TEMP TABLE bug2_pid (pid int);
  INSERT INTO bug2_pid VALUES (pg_backend_pid()); -- pid_1


  DO $$
  DECLARE cnt int;
  BEGIN
      SET LOCAL enable_hashjoin = off;
      SET LOCAL enable_mergejoin = off;


      SELECT count(*) INTO cnt
      FROM ft_big b, ft_small s
      WHERE b.id = s.id
        AND pg_backend_pid() > 0;


      RAISE NOTICE 'completed: cnt=%', cnt;


  EXCEPTION WHEN OTHERS THEN
      RAISE NOTICE 'caught: %', SQLERRM;
  END;
  $$;


  SELECT 'post_check' AS phase, count(*) FROM ft_big; -- CRASH HERE


session-2
SELECT pid FROM bug2_pid;
SELECT pg_cancel_backend(pid); -- After Session 1 enters the drain loop, execute pg_cancel_backend(pid) in Session 2.


I believe the issue regarding fsstate->conn and active_fsstate->conn that you've been discussing with Robert is related to this crash.
If only one PgFdwScanState* (active_fsstate) is available inside save_to_tuplestore, the assignment active_scan = NULL will clearly not be executed prior to draining.
The draining logic operates on data from active_fsstate, and we can only clear it after draining completes successfully.


Best regards,

--

Yilin Zhang