Re: Bypassing cursors in postgres_fdw to enable parallel plans - Mailing list pgsql-hackers

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