| From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> | 
|---|---|
| To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> | 
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: inserts into partitioned table may cause crash | 
| Date: | 2018-03-06 06:28:21 | 
| Message-ID: | babd9f1a-fea5-de68-8eff-1aa13a10873a@lab.ntt.co.jp | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
Fujita-san,
Thanks for the review.
On 2018/03/05 22:00, Etsuro Fujita wrote:
> I started reviewing this.  I think the analysis you mentioned upthread
> would be correct, but I'm not sure the patch is the right way to go
> because I think that exception handling added by the patch throughout
> ExecInsert such as:
> 
> @@ -408,7 +408,10 @@ ExecInsert(ModifyTableState *mtstate,
>                 slot = ExecBRInsertTriggers(estate, resultRelInfo, slot);
> 
>                 if (slot == NULL)               /* "do nothing" */
> -                       return NULL;
> +               {
> +                       result = NULL;
> +                       goto restore_estate_result_rel;
> +               }
> 
> would reduce the code readability.
Hmm yeah, it is a bit hacky.
> An alternative fix for this would be to handle the set/reset of
> estate->es_result_relation_info in a higher level ie, ExecModifyTable,
> like the attached: (1) before calling ExecInsert, we do the preparation
> work for tuple routing of one tuple (eg, determine the partition for the
> tuple and convert the format of the tuple in a separate function, which
> also sets estate->es_result_relation_info to the partition for ExecInsert
> to work on it; then (2) we call ExecInsert, which just inserts into the
> partition; then (3) we reset estate->es_result_relation_info back to the
> root partitioned table.  One good thing about the alternative is to return
> ExecInsert somehow to PG9.6, which would make maintenance easier.  COPY
> has the same issue, so the attached also fixes that.  (Maybe we could do
> some refactoring to use the same code in both cases, but I'm not sure we
> should do that as a fix.)  What do you think about the alternative?
Your patch seems like a good cleanup overall, fixes this bug, and seems to
make future maintenance easier.  So, +1.  I agree that doing a surgery
like this on COPY is better left for later.
I noticed (as you may have too) that it cannot be applied to the 10 branch
as is.  I made the necessary changes so that it can be.  See attached
patch with filename suffixed "-10backpatch".  Also attached is your patch
unchanged to have both of them together.
Thanks,
Amit
| Attachment | Content-Type | Size | 
|---|---|---|
| ExecInsert-reset-estate-result-rel-efujita.patch | text/plain | 12.4 KB | 
| ExecInsert-reset-estate-result-rel-efujita-10backpatch.patch | text/plain | 9.4 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2018-03-06 07:21:24 | Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)? | 
| Previous Message | Pavel Stehule | 2018-03-06 06:14:00 | Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs |