On 2015/03/13 11:46, Etsuro Fujita wrote:
BTW, what do you think about opening/locking foreign tables selected for
update at InitPlan, which the original patch does? As I mentioned in
[1], ISTM that ExecOpenScanRelation called from ExecInitForeignScan is
assuming that.
[1] http://www.postgresql.org/message-id/54bcbbf8.3020...@lab.ntt.co.jp
Let me explain further. Here is the comment in ExecOpenScanRelation:
* Determine the lock type we need. First, scan to see if target
relation
* is a result relation. If not, check if it's a FOR UPDATE/FOR SHARE
* relation. In either of those cases, we got the lock already.
I think this is not true for foreign tables selected FOR UPDATE/SHARE,
which have markType = ROW_MARK_COPY, because such foreign tables don't
get opened/locked by InitPlan. Then such foreign tables don't get
locked by neither of InitPlan nor ExecOpenScanRelation. I think this is
a bug. To fix it, I think we should open/lock such foreign tables at
InitPlan as the original patch does.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
