Re: Column Filtering in Logical Replication

Поиск
Список
Период
Сортировка
От Rahila Syed
Тема Re: Column Filtering in Logical Replication
Дата
Msg-id CAH2L28vZzcKQPV18EuwZG0wUr=E5g+E9WEbejtX-hEpjvJLLvg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Column Filtering in Logical Replication  (Peter Smith <smithpb2250@gmail.com>)
Ответы Re: Column Filtering in Logical Replication  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Список pgsql-hackers
Hi Peter,

Hi, I was wondering if/when a subset of cols is specified then does
that mean it will be possible for the table to be replicated to a
*smaller* table at the subscriber side? 
e.g Can a table with 7 cols replicated to a table with 2 cols?

table tab1(a,b,c,d,e,f,g) --> CREATE PUBLICATION pub1 FOR TABLE
tab1(a,b)  --> table tab1(a,b)

~~

I thought maybe that should be possible, but the expected behaviour
for that scenario was not very clear to me from the thread/patch
comments. And the new TAP test uses the tab1 table created exactly the
same for pub/sub, so I couldn't tell from the test code either.
 
Currently, this capability is not included in the patch. If the table on the subscriber
server has lesser attributes than that on the publisher server, it throws an error at the 
time of CREATE SUBSCRIPTION.

About having such a functionality, I don't immediately see any issue with it as long
as we make sure replica identity columns are always present on both instances.
However, need to carefully consider situations in which a server subscribes to multiple 
publications,  each publishing a different subset of columns of a table.  
 

Thank you,
Rahila Syed

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Can a child process detect postmaster death when in pg_usleep?
Следующее
От: David Rowley
Дата:
Сообщение: Re: Remove useless int64 range checks on BIGINT sequence MINVALUE/MAXVALUE values