Re: speed up a logical replica setup
От | Amit Kapila |
---|---|
Тема | Re: speed up a logical replica setup |
Дата | |
Msg-id | CAA4eK1JRgnhv_ySzuFjN7UaX9qxz5Hqcwew7Fk=+AbJbu0Kd9w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: speed up a logical replica setup ("Euler Taveira" <euler@eulerto.com>) |
Ответы |
RE: speed up a logical replica setup
|
Список | pgsql-hackers |
On Thu, Jan 11, 2024 at 7:59 AM Euler Taveira <euler@eulerto.com> wrote: > > On Wed, Jan 10, 2024, at 1:33 AM, Shlok Kyal wrote: > > Here the standby node would be waiting for the 'consistent_lsn' wal > during recovery but this wal will not be present on standby if no > physical replication is setup. Hence the command will be waiting > infinitely for the wal. > > > Hmm. Some validations are missing. > > To solve this added a timeout of 60s for the recovery process and also > added a check so that pg_subscriber would give a error when it called > for node which is not in physical replication. > Have attached the patch for the same. It is a top-up patch of the > patch 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.) > Right, such a check will reduce some complexity. So, +1 for the check as proposed by Shlok. Also, what are your thoughts on a timeout during the wait? I think it is okay to wait for 60s by default but there should be an option for users to wait for longer. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: