Re: We need to support ForeignRecheck for late row locking, don't we?
От | Etsuro Fujita |
---|---|
Тема | Re: We need to support ForeignRecheck for late row locking, don't we? |
Дата | |
Msg-id | 55B204A0.1080507@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | We need to support ForeignRecheck for late row locking, don't we? (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: We need to support ForeignRecheck for late row
locking, don't we?
|
Список | pgsql-hackers |
On 2015/07/22 19:10, Etsuro Fujita wrote: > While working on the issue "Foreign join pushdown vs EvalPlanQual", I > happened to notice odd behaviors of late row locking in FDWs. > I think the reason for that is because we don't check pushed-down quals > inside an EPQ testing even if what was fetched by RefetchForeignRow was > an updated version of the tuple rather than the same version previously > obtained. So, to fix this, I'd like to propose that pushed-down quals > be checked in ForeignRecheck. Attached is a patch for that. * I've modified ForeignRecheck so as to check pushed-down quals whether doing late locking or early locking. I think we could probably make ForeignRecheck do so only when doing late locking, but I'm not sure it's worth complicating the code. * I've made the above change only for simple foreign table scans that have scanrelid > 0 and fdw_scan_tlist = NIL. As for simple foreign table scans that have scanrelid > 0 and *fdw_scan_tlist is non-NIL*, I think we are under discussion in another thread I started. Will update as necessary. * Sorry, I've not fully updated comments and docs yet. Will update. I'd be happy if I could get feedback earlier. Best regards, Etsuro Fujita
Вложения
В списке pgsql-hackers по дате отправления: