| From: | Chris Angelico <rosuav(at)gmail(dot)com> |
|---|---|
| To: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Logical replication claims to work, not working - new tables |
| Date: | 2024-01-21 18:50:57 |
| Message-ID: | CAPTjJmq_w2sqrgBXZXX3sGid8e2AKE5a6pRAMe6B01nxsYS05w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, 22 Jan 2024 at 05:25, Justin <zzzzz(dot)graf(at)gmail(dot)com> wrote:
>
> When using replica set to full this kicks off a full table scan for each update or delete this is very expensive. If there are no errors being reported you will find it is working but hung doing full scans. Inserts are just appended to end 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 is set 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris Angelico | 2024-01-21 19:28:09 | Re: Logical replication claims to work, not working - new tables |
| Previous Message | Justin | 2024-01-21 18:25:37 | Re: Logical replication claims to work, not working - new tables |