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
|
Список | 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 по дате отправления: