search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault

Поиск
Список
Период
Сортировка
От David Geier
Тема search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault
Дата
Msg-id 0253344d-9bdd-11c4-7f0d-d88c02cd7991@swarm64.com
обсуждение исходный текст
Ответы Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault  (Zhihong Yu <zyu@yugabyte.com>)
Re: search_plan_tree(): handling of non-leaf CustomScanState nodes causes segfault  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi hackers,

While working with cursors that reference plans with CustomScanStates 
nodes, I encountered a segfault which originates from 
search_plan_tree(). The query plan is the result of a simple SELECT 
statement into which I inject a Custom Scan node at the root to do some 
post-processing before returning rows. This plan is referenced by a 
second plan with a Tid Scan which originates from a query of the form 
DELETE FROM foo WHERE CURRENT OF my_cursor;

search_plan_tree() assumes that 
CustomScanState::ScanState::ss_currentRelation is never NULL. In my 
understanding that only holds for CustomScanState nodes which are at the 
bottom of the plan and actually read from a relation. CustomScanState 
nodes which are not at the bottom don't have ss_currentRelation set. I 
believe for such nodes, instead search_plan_tree() should recurse into 
CustomScanState::custom_ps.

I attached a patch. Any thoughts?

Best regards,
David
Swarm64


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Allow matching whole DN from a client certificate
Следующее
От: Peter Smith
Дата:
Сообщение: Re: Single transaction in the tablesync worker?