Re: PG13 partitioned table logical replication
| От | Peter Eisentraut |
|---|---|
| Тема | Re: PG13 partitioned table logical replication |
| Дата | |
| Msg-id | 54c6aa94-5e78-854c-f2d8-dc6d625acfb0@2ndquadrant.com обсуждение исходный текст |
| Ответ на | PG13 partitioned table logical replication (Nicolas Sornin <nicolas.sornin@actia.be>) |
| Ответы |
RE: PG13 partitioned table logical replication
|
| Список | pgsql-general |
On 2020-09-10 14:13, Nicolas Sornin wrote: > I just made some test of upcoming version of porstgresql, especially the > ability to publish partitioned table via root partition. > > I tried to setup PG13 to PG12 replication with different partitioning > schemes. > > My first attempt was to replicate time partitioned table in PG13 cluster > to a regular table in PG12 cluster, but after looking at the logs I saw > the following error : > > 2020-09-09 12:21:33.964 CEST [22976] LOG: logical replication table > synchronization worker for subscription "rep_part_sub", table > "stock_sales" has started > > 2020-09-09 12:21:33.997 CEST [22976] ERROR: table "public.stock_sales" > not found on publisher > > 2020-09-09 12:21:33.999 CEST [20346] LOG: background worker "logical > replication worker" (PID 22976) exited with exit code 1 > > While not being aware of underlying mechanics of logical replication, I > was expecting this use case to work given table names and column > names/types are the same on both sides. > > Is this the intended behavior and simply out of the scope of the changes > introduced by PG13 ? When the subscriber running on PG12 is trying to fetch information about the table from the publisher, it is looking for a real table, which it doesn't find, because it's a partitioned table. So this combination doesn't work. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-general по дате отправления: