Re: row filtering for logical replication

From: Euler Taveira <euler(at)timbira(dot)com(dot)br>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: row filtering for logical replication
Date: 2018-03-01 23:15:37
Message-ID: CAHE3wghpw3n0BYr3ewoXA=d+cOaP3NDa-+4jKkitdQpkzqhJdw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2018-02-28 21:54 GMT-03:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:
> Good idea. I haven't read this yet, but one thing to make sure you've
> handled is limiting the clause to referencing only the current tuple and the
> catalogs. user-catalog tables are OK, too, anything that is
> RelationIsAccessibleInLogicalDecoding().
>
> This means only immutable functions may be invoked, since a stable or
> volatile function might attempt to access a table. And views must be
> prohibited or recursively checked. (We have tree walkers that would help
> with this).
>
> It might be worth looking at the current logic for CHECK expressions, since
> the requirements are similar. In my opinion you could safely not bother with
> allowing access to user catalog tables in the filter expressions and limit
> them strictly to immutable functions and the tuple its self.
>
IIRC implementation is similar to RLS expressions. I'll check all of
these rules.

--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2018-03-01 23:16:17 Re: row filtering for logical replication
Previous Message Andres Freund 2018-03-01 23:07:12 Re: Challenges preventing us moving to 64 bit transaction id (XID)?