| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com> |
| Cc: | KENAN YILMAZ <kenan(dot)yilmaz(at)localus(dot)com(dot)tr>, Andy Fan <zhihuifan1213(at)163(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Bypassing cursors in postgres_fdw to enable parallel plans |
| Date: | 2026-06-26 19:42:14 |
| Message-ID: | CA+Tgmob_HYowO3E3bshpqDjRCd-t==UE_q_92kvSx=207YKx8w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 23, 2026 at 5:38 AM Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com> wrote:
> I understand your concern and I tried to solve it by passing fsstate now, also saving a backpointer to the node in active_fsstate to solve the issue with make_tuple_from_result_row. Since we need to have conn from fsstate, I am not sure how we can do that if we have only active_fsstate passed to the function.
If fsstate->conn and active_fsstate->conn can be different, I think we
have a big problem. The idea of save_to_tuplestore() is that there's a
query running on the connection already and we have to finish reading
its results before we can use the connection for something else. But
that only makes sense if it's the SAME connection in both cases. If
we're running a connection on connection A, there's no reason we need
to do anything before sending a new query on connection B.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ian Lawrence Barwick | 2026-06-26 19:46:26 | Re: DOCS - "Get Object DDL Functions" table improvements |
| Previous Message | Dean Rasheed | 2026-06-26 19:37:07 | Re: Global temporary tables |