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?  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
Список 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 по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: pgbench - allow backslash-continuations in custom scripts
Следующее
От: Nicolas Barbier
Дата:
Сообщение: Re: Eliminating CREATE INDEX comparator TID tie-breaker overhead