Re: Column Filtering in Logical Replication

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Column Filtering in Logical Replication
Дата
Msg-id 202112172107.i5ebyfyrifk7@alvherre.pgsql
обсуждение исходный текст
Ответ на Column Filtering in Logical Replication  (Rahila Syed <rahilasyed90@gmail.com>)
Ответы Re: Column Filtering in Logical Replication  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Re: Column Filtering in Logical Replication  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
So I've been thinking about this as a "security" item (you can see my
comments to that effect sprinkled all over this thread), in the sense
that if a publication "hides" some column, then the replica just won't
get access to it.  But in reality that's mistaken: the filtering that
this patch implements is done based on the queries that *the replica*
executes at its own volition; if the replica decides to ignore the list
of columns, it'll be able to get all columns.  All it takes is an
uncooperative replica in order for the lot of data to be exposed anyway.

If the server has a *separate* security mechanism to hide the columns
(per-column privs), it is that feature that will protect the data, not
the logical-replication-feature to filter out columns.


This led me to realize that the replica-side code in tablesync.c is
totally oblivious to what's the publication through which a table is
being received from in the replica.  So we're not aware of a replica
being exposed only a subset of columns through some specific
publication; and a lot more hacking is needed than this patch does, in
order to be aware of which publications are being used.

I'm going to have a deeper look at this whole thing.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/



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

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: speed up text_position() for utf-8
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Adding CI to our tree