Re: speed up a logical replica setup
| От | Euler Taveira |
|---|---|
| Тема | Re: speed up a logical replica setup |
| Дата | |
| Msg-id | bcd3db13-f56e-47e3-8fa7-7f0c6243c8a6@app.fastmail.com обсуждение исходный текст |
| Ответ на | Re: speed up a logical replica setup (Shlok Kyal <shlok.kyal.oss@gmail.com>) |
| Ответы |
Re: speed up a logical replica setup
|
| Список | pgsql-hackers |
On Wed, Jan 10, 2024, at 1:33 AM, Shlok Kyal wrote:
Here the standby node would be waiting for the 'consistent_lsn' walduring recovery but this wal will not be present on standby if nophysical replication is setup. Hence the command will be waitinginfinitely for the wal.
Hmm. Some validations are missing.
To solve this added a timeout of 60s for the recovery process and alsoadded a check so that pg_subscriber would give a error when it calledfor node which is not in physical replication.Have attached the patch for the same. It is a top-up patch of thepatch shared by Euler at [1].
If the user has a node that is not a standby and it does not set the GUCs to
start the recovery process from a backup, the initial setup is broken. (That's
the case you described.) A good UI is to detect this scenario earlier.
Unfortunately, there isn't a reliable and cheap way to do it. You need to start
the recovery and check if it is having some progress. (I don't have a strong
opinion about requiring a standby to use this tool. It would reduce the
complexity about checking if the setup has all requirements to run this tool.)
В списке pgsql-hackers по дате отправления: