Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-eddata

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-eddata
Дата
Msg-id 7a4f2548-d574-c9e4-620f-cae4f00ffb45@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-eddata  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: logical decoding vs. VACUUM FULL / CLUSTER on table with TOAST-eddata  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
On 11/19/18 11:44 AM, Tomas Vondra wrote:
> On 11/19/18 10:28 AM, Masahiko Sawada wrote:
>> On Mon, Nov 19, 2018 at 6:52 AM Tomas Vondra
>> <tomas.vondra@2ndquadrant.com> wrote:
>>>
>>> ...
>>>
>>> This does fix the issue, because we still decode the TOAST changes but
>>> there are no data and so
>>>
>>>      if (change->data.tp.newtuple != NULL)
>>>      {
>>>          dlist_delete(&change->node);
>>>          ReorderBufferToastAppendChunk(rb, txn, relation,
>>>                                        change);
>>>      }
>>>
>>> ends up not stashing the change in the hash table.
>>
>> With the below change you proposed can we remove the above condition
>> because toast-insertion changes being processed by the reorder buffer
>> always have a new tuple? If a toast-insertion record doesn't have a
>> new tuple it has already ignored when decoding.
>>
> 
> Good point. I think you're right the reorderbuffer part may be
> simplified as you propose.
> 

OK, here's an updated patch, tweaking the reorderbuffer part. I plan to
push this sometime mid next week.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Вложения

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pg_upgrade supported versions policy
Следующее
От: David Rowley
Дата:
Сообщение: Re: Inadequate executor locking of indexes