Re: Logical replication claims to work, not working - new tables
От | Chris Angelico |
---|---|
Тема | Re: Logical replication claims to work, not working - new tables |
Дата | |
Msg-id | CAPTjJmq_w2sqrgBXZXX3sGid8e2AKE5a6pRAMe6B01nxsYS05w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical replication claims to work, not working - new tables (Justin <zzzzz.graf@gmail.com>) |
Ответы |
Re: Logical replication claims to work, not working - new tables
|
Список | pgsql-general |
On Mon, 22 Jan 2024 at 05:25, Justin <zzzzz.graf@gmail.com> wrote: > > When using replica set to full this kicks off a full table scan for each update or delete this is very expensive. Ifthere are no errors being reported you will find it is working but hung doing full scans. Inserts are just appended toend of heap. > That shouldn't be too costly, since this table only has a single row in it. But it never finishes the replication at all. > > You can copy the replication slot on the primary to peak at which transactions LR is hung on to confirm. > > Adding a primary key will fix this issue. Note PG 16 can use indexes to find qualifying rows when a table's replica isset to full. Ah, sadly PG 16 isn't an option as yet. It would definitely make dual-master replication somewhat easier. I'll try dropping the table, creating it again with a PK, and seeing how it goes. Thanks. ChrisA
В списке pgsql-general по дате отправления: