Re: EvalPlanQual behaves oddly for FDW queries involving system columns

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, ashutosh(dot)bapat(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: EvalPlanQual behaves oddly for FDW queries involving system columns
Date: 2015-04-16 06:55:27
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2015/04/15 2:27, Jim Nasby wrote:
> On 4/14/15 1:05 AM, Kyotaro HORIGUCHI wrote:
>> As an example, the following operations cause an "unexpected"
>> result.

> Those results are indeed surprising, but since we allow it in a direct
> connection I don't see why we wouldn't allow it in the Postgres FDW...
> As for the FDW not knowing about keys, why would it need to? If you try
> to do something illegal it's the remote side that should throw the
> error, not the FDW.
> Of course, if you try to do a locking operation on an FDW that doesn't
> support it, the FDW should throw an error... but that's different.

Ah, you are right. FOR NO KEY UPDATE and FOR KEY SHARE would be useful
in the Postgres FDW if we assume the user performs those properly based
on information about keys for a remote table.

Sorry, my explanation was not correct, but I want to make it clear that
the proposed patch also allows the FDW to change the behavior of FOR NO
KEY UPDATE and/or FOR KEY SHARE row locking so as to match the local
semantics exactly.

BTW, I revised docs a bit. Attached is an updated version of the patch.

Best regards,
Etsuro Fujita

Attachment Content-Type Size
EvalPlanQual-v6.patch text/x-diff 18.4 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2015-04-16 07:05:45 Re: inherit support for foreign tables
Previous Message Michael Paquier 2015-04-16 06:46:32 Supporting src/test/modules in MSVC builds