Re: Support logical replication of DDLs

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Support logical replication of DDLs
Дата
Msg-id CAA4eK1+4q0F862OfHkL7R1HQgEaCH9HMQLEFPBnpU=-vAay-MQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support logical replication of DDLs  (Ajin Cherian <itsajin@gmail.com>)
Ответы RE: Support logical replication of DDLs  (Phil Florent <philflorent@hotmail.com>)
Список pgsql-hackers
On Sun, Apr 2, 2023 at 3:25 PM Phil Florent <philflorent@hotmail.com> wrote:
>
> As an end-user, I am highly interested in the patch https://commitfest.postgresql.org/42/3595/ but I don't fully get
itsmain goal in its first version. 
> It's "for all tables"  that will be implemented ?
> If one needs a complete replication of a cluster, a hot standby will always be more efficient than a publication
right? I use both for different needs in public hospitals I work for (hot standby for disaster recovery & logical
replicationfor dss) 
> The main interest of a publication is to be able to filter things on the publisher and to add stuff on the replicated
cluster.
> If you compare PostgreSQL with less avanced RDBMS that don't really implement schemas (typically Oracle), the huge
advantageof Postgre is that many things (e.g security) can be dynamically implemented via schemas. 
> Developers just have put a table in the "good" schema and that's all. Logical DML replication now fully implements
thislogic since PostgreSQL 15. Only remaining problem is that a "for tables in schema" publication has to be owned by a
superuser(because a normal user can have tables that don't belong to him in a schema it owns ?) If DDL replication only
workswith "FOR ALL TABLES " and not "FOR TABLES IN SCHEMA" it reduces its interest anyway. 
>

I don't see any major issue with supporting it for both "FOR ALL
TABLES" and "FOR ALL TABLES IN SCHEMA". However, if we want to support
it with the "FOR TABLE .." variant then we will probably need to apply
some restrictions as we can only support 'alter' and 'drop'.
Additionally, there could be some additional problems to deal with
like say if the column list has been specified then we ideally
shouldn't send those columns even in DDL. For example, if one uses
Alter Table .. Rename Column and the new column name is not present in
the published column list then we shouldn't send it.

BTW, we have some proposals related to the specification of this
feature in emails [1][2][3]. See, if you have any suggestions on the
same?

Note- It seems you have copied this thread to pgsql-general. Is it
because you are not subscribed to pgsql-hackers? As this is a
development project so better to keep the discussion on pgsql-hackers.

[1] -
https://www.postgresql.org/message-id/CAA4eK1%2B%2BY7a2SQq55DXT6neghZgj3j%2BpQ74%3D8zfT3k8Tkdj0ZA%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/CAA4eK1KZqvJsTt7OkS8AkxOKVvSpkQkPwsqzNmo10mFaVAKeZg%40mail.gmail.com
[3] -
https://www.postgresql.org/message-id/OS0PR01MB571646874A3E165D93999A9D94889%40OS0PR01MB5716.jpnprd01.prod.outlook.com

--
With Regards,
Amit Kapila.



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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Следующее
От: Pavel Luzanov
Дата:
Сообщение: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)