Re: row filtering for logical replication

Поиск
Список
Период
Сортировка
От Dilip Kumar
Тема Re: row filtering for logical replication
Дата
Msg-id CAFiTN-sE0W0WQMvz5+5D+V=cvZ-RD=nTBc8+fDvDWXB=hp9z-A@mail.gmail.com
обсуждение исходный текст
Ответ на RE: row filtering for logical replication  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Ответы Re: row filtering for logical replication
Re: row filtering for logical replication
Список pgsql-hackers
On Tue, Jul 27, 2021 at 6:21 AM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:

> 1) UPDATE a nonkey column in publisher.
> 2) Use debugger to block the walsender process in function
>    pgoutput_row_filter_exec_expr().
> 3) Open another psql to connect the publisher, and drop the table which updated
>    in 1).
> 4) Unblock the debugger in 2), and then I can see the following error:
> ---
> ERROR:  could not read block 0 in file "base/13675/16391"

Yeah, that's a big problem, seems like the expression evaluation
machinery directly going and detoasting the externally stored data
using some random snapshot.  Ideally, in walsender we can never
attempt to detoast the data because there is no guarantee that those
data are preserved.  Somehow before going to the expression evaluation
machinery, I think we will have to deform that tuple and need to do
something for the externally stored data otherwise it will be very
difficult to control that inside the expression evaluation.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



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

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [PoC] Improve dead tuple storage for lazy vacuum
Следующее
От: David Rowley
Дата:
Сообщение: Re: Slim down integer formatting