Re: BUG #18027: Logical replication taking forever

Поиск
Список
Период
Сортировка
От Andres Martin del Campo Campos
Тема Re: BUG #18027: Logical replication taking forever
Дата
Msg-id CALZDMc=ubT2v6xVn60ojt3ypAE2kmYvZPG3KXM-Y-fyS3Hp40g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #18027: Logical replication taking forever  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-bugs
Thank you Amit! 
Here's the publisher:
 image.png

Here's the subscriber:
image.png

I don't see any errors in the logs but if you have time I would love to schedule a quick meeting with you and compensate you for your time of course.

Let me know if you are available

On Fri, Jul 21, 2023 at 11:26 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Jul 20, 2023 at 10:46 PM Andres Martin del Campo Campos <andres@invisible.email> wrote:
Seems like I don't have that table


 image.png


There are no errors in the logs but I only see dead tuples and no live tuples


oh, can you show us the dead and live tuple count on both publisher and subscriber? Ideally, COPY command should only copy the recent data based on the snapshot. It shouldn't copy the old/dead rows. One possibility I could think of is that due to some reason, if there is a failure during the initial sync process, it will ROLLBACK the whole copy and restart it again. So, that way one can see the table is growing with dead tuples and the copy is never finished especially if such an error occurs repeatedly. If that happens, you must see some error in the subscriber-side logs. Can you ensure in some way that such a phenomenon is not happening in your case?

--
With Regards,
Amit Kapila.
Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_hba.conf "authentication file token too long, skipping"
Следующее
От: "Jonathan S. Katz"
Дата:
Сообщение: Re: BUG #18018: Homebrew link is broken