Re: speed up a logical replica setup
От | Euler Taveira |
---|---|
Тема | Re: speed up a logical replica setup |
Дата | |
Msg-id | 6aa1b0d7-a4e9-46b1-9990-3ae1d22e1952@app.fastmail.com обсуждение исходный текст |
Ответ на | Re: speed up a logical replica setup (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: speed up a logical replica setup
|
Список | pgsql-hackers |
On Mon, Mar 25, 2024, at 11:33 PM, Amit Kapila wrote:
On Mon, Mar 25, 2024 at 5:25 PM Peter Eisentraut <peter@eisentraut.org> wrote:>> I have committed your version v33. I did another pass over the> identifier and literal quoting. I added quoting for replication slot> names, for example, even though they can only contain a restricted set> of characters, but it felt better to be defensive there.>> I'm happy to entertain follow-up patches on some of the details like> option naming that were still being discussed. I just wanted to get the> main functionality in in good time. We can fine-tune the rest over the> next few weeks.>I was looking at prior discussions on this topic to see if there areany other open design points apart from this and noticed that thepoints raised/discussed in the email [1] are also not addressed. IIRC,the key point we discussed was that after promotion, the existingreplication objects should be removed (either optionally or always),otherwise, it can lead to a new subscriber not being able to restartor getting some unwarranted data.
See setup_subscriber.
/*
* Since the publication was created before the consistent LSN, it is
* available on the subscriber when the physical replica is promoted.
* Remove publications from the subscriber because it has no use.
*/
drop_publication(conn, &dbinfo[i]);
В списке pgsql-hackers по дате отправления: