RE: Parallel INSERT (INTO ... SELECT ...)

Поиск
Список
Период
Сортировка
От Hou, Zhijie
Тема RE: Parallel INSERT (INTO ... SELECT ...)
Дата
Msg-id 77e1c06ffb2240838e5fc94ec8dcb7d3@G08CNEXMBPEKD05.g08.fujitsu.local
обсуждение исходный текст
Ответ на Re: Parallel INSERT (INTO ... SELECT ...)  (Greg Nancarrow <gregn4422@gmail.com>)
Ответы Re: Parallel INSERT (INTO ... SELECT ...)  (Greg Nancarrow <gregn4422@gmail.com>)
Список pgsql-hackers
Hi

> Posting an updated set of patches to address recent feedback:
> 
> - Removed conditional-locking code used in parallel-safety checking code
> (Tsunakawa-san feedback). It turns out that for the problem test case, no
> parallel-safety checking should be occurring that locks relations because
> those inserts are specifying VALUES, not an underlying SELECT, so the
> parallel-safety checking code was updated to bail out early if no underlying
> SELECT is specified for the INSERT. No change to the test code was required.
> - Added comment to better explain the reason for treating "INSERT ...
> ON CONFLICT ... DO UPDATE" as parallel-unsafe (Dilip)
> - Added assertion to heap_prepare_insert() (Amit)
> - Updated error handling for NULL index_expr_item case (Vignesh)

+
+    index_oid_list = RelationGetIndexList(rel);
...

As memtioned in the comments of RelationGetIndexList:
* we return a copy of the list palloc'd in the caller's context.  The caller
* may list_free() the returned list after scanning it.

Shall we list_free(index_oid_list) at the end of function ?
Just to avoid potential memory leak.

Best regards,
houzj




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

Предыдущее
От: "Hou, Zhijie"
Дата:
Сообщение: RE: Parallel Inserts in CREATE TABLE AS
Следующее
От: Tom Lane
Дата:
Сообщение: Re: \gsetenv