a new problem in MERGE

Поиск
Список
Период
Сортировка
От Boxuan Zhai
Тема a new problem in MERGE
Дата
Msg-id AANLkTikjvNC0EzU+YDPVc3QuRTnafze01ry9vofNyvL+@mail.gmail.com
обсуждение исходный текст
Ответы Re: a new problem in MERGE  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-hackers
Dear Greg, 

How are you?

As we talked last week, there is a bug about the "origslot" field assertion. 
 
TRAP: FailedAssertion("!(epqstate->origslot != ((void *)0))", File: "execMain.c", Line: 1732)


I checked my codes and found the reason of this problem. In the original process of "ExecModifyTable()" function, there is a line of code  "EvalPlanQualSetSlot(&node->mt_epqstate, planSlot);"

It is specially used to init the epqstate->origslot field with the tuple slot returned by the underlying plan. However, in our implementation of MERGE, this part is missed in "ExecMerge()" function. 

At the beginning, I just tried to form a new slot in "ExecMerge()" and use it as the epqstate->origslot for the merge actions' execution functions. This part is simple. 

But, during this process, I found a more serious problem: our MERGE currently does not support the use of system attributes in the action conditions and target lists. 

For example, if we raise queries like the following, there will pops some ERROR message. 

(table target has oid attribute)
MERGE INTO target t USING source  s ON t.id = s.id
WHEN MATCHED AND t.oid >100000 THEN update SET val = t.val + s.add;

or 

MERGE INTO target t USING source  s ON t.id = s.id
WHEN MATCHED AND t.xmin = 1000 THEN update SET val = t.val + s.add;



The reason for the above problem is the missing of system attribute in the result slot returned by the main plan of MERGE. 

In our implementation,  the Main Pan of MERGE just generate a tuple slot contain all the direct vars from source table and target table. The expressions in MERGE action conditions and target lists are then calculated based on the result slot of main plan. 

Currently, all the system attributes (except the ctid of target table) are not included in main plan. So, the evaluation of action condition and target entries will fail if they involve some system attributes. 

If we want to solve this problem, we need to extend the target list of main plan before execution (in analyzer or planner), make sure it contains all the attributes appeared in any of the MERGE actions. This may lead to adjustments to many part of the process of MERGE. For example, within the planner, I created a function specially for mapping the Var nodes in actions to attributes in the result slot. This function should be rewritten for this new case.  

I have plan to fix the above two bugs together. (in fact, I have already started coding in merge_v202 edition). My question is how should I make my update be consistent with yours. Is it possible for you to give me an edition that I can work on? 

Thanks!

Yours Boxuan

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Maximum function call nesting depth for regression tests
Следующее
От: Peter Eisentraut
Дата:
Сообщение: type info refactoring