On Tue, Nov 28, 2017 at 11:05 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Nov 28, 2017 at 11:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In short, we should get rid of all of this expensive and broken logic and
>> just make EPQ recheck on a foreign join be a no-op, just as it is for a
>> foreign base table.
>
> I'm not sure that it is. What of
> 5fc4c26db5120bd90348b6ee3101fcddfdf54800? That was before I started
> putting "Discussion" links into commit messages as a matter of
> routine, but I'm pretty sure that fixed what seemed to Etsuro Fujita,
> Kyotaro Horiguchi, and myself to be pretty clear misbehavior. See
> also 385f337c9f39b21dca96ca4770552a10a6d5af24. We've put an awful lot
> of effort into this over the last few years; I'm a bit hesitant to
> believe none of that did anything.
>
IIUC, the problem here is not about stale foreign tuples (or whether
they can change) - as you described above they can not, since we have
requested FOR UPDATE. But when a foreign join is further joined with a
local table, tuples in which change after they are joined, we need to
make sure that the total join tuple (local table joined with foreign
join) still qualifies. We do this by locally joining those rows again.
[1] is where the discussion started
[1] https://www.postgresql.org/message-id/558A18B3.9050201@lab.ntt.co.jp
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
