On Tue, Nov 28, 2017 at 11:05 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Nov 28, 2017 at 11:21 AM, Tom Lane <t...@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.9050...@lab.ntt.co.jp -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
