From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: bug in update tuple routing with foreign partitions |
Date: | 2019-04-19 03:15:11 |
Message-ID: | 5CB93D3F.6050903@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(2019/04/18 22:10), Etsuro Fujita wrote:
> Notes:
>
> * I kept all the changes in the previous patch, because otherwise
> postgres_fdw would fail to release resources for a foreign-insert
> operation created by postgresBeginForeignInsert() for a tuple-routable
> foreign table (ie, a foreign-table subplan resultrel that has been
> updated already) during postgresEndForeignInsert().
I noticed that this explanation was not right. Let me correct myself.
The reason why I kept those changes is: without those changes, we would
fail to release the resources for a foreign-update operation (ie,
fmstate) created by postgresBeginForeignModify(), replaced by the
fmstate for the foreign-insert operation, because when doing
ExecEndPlan(), we first call postgresEndForeignModify() and then call
postgresEndForeignInsert(); so, if we didn't keep those changes, we
would *mistakenly* release the fmstate for the foreign-insert operation
in postgresEndForeignModify(), and we wouldn't do anything about the
fmstate for the foreign-update operation in that function and in the
subsequent postgresEndForeignInsert().
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Guo | 2019-04-19 03:40:04 | Re: Two pg_rewind patches (auto generate recovery conf and ensure clean shutdown) |
Previous Message | Peter Geoghegan | 2019-04-19 03:13:44 | Re: Pathological performance when inserting many NULLs into a unique index |