Re: speed up a logical replica setup

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: Euler Taveira <euler@eulerto.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Andres Freund <andres@anarazel.de>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Michael Paquier <michael@paquier.xyz>, Peter Eisentraut <peter@eisentraut.org>
Date: 2024-01-08T05:29:54Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. pg_createsubscriber: Remove obsolete comment

  2. pg_createsubscriber: Fix an unpredictable recovery wait time.

  3. Fix unstable test in 040_pg_createsubscriber.

  4. Fix the testcase introduced in commit 81d20fbf7a.

  5. Further weaken new pg_createsubscriber test on Windows.

  6. Temporarily(?) weaken new pg_createsubscriber test on Windows.

  7. Make pg_createsubscriber warn if publisher has two-phase commit enabled.

  8. Make pg_createsubscriber more wary about quoting connection parameters.

  9. pg_createsubscriber: Remove failover replication slots on subscriber

  10. pg_createsubscriber: Remove replication slot check on primary

  11. pg_createsubscriber: Only --recovery-timeout controls the end of recovery process

  12. pg_createsubscriber: creates a new logical replica from a standby server

  13. Add some const decorations

  14. Add option force_initdb to PostgreSQL::Test::Cluster:init()

  15. Remove MSVC scripts

On Fri, Jan 5, 2024 at 3:36 PM Hayato Kuroda (Fujitsu)
<kuroda.hayato@fujitsu.com> wrote:
>
> I love your proposal, so I want to join the review. Here are my first comments.
>
> 01.
> Should we restrict that `--subscriber-conninfo` must not have hostname or IP?
> We want users to execute pg_subscriber on the target, right?
>

I don't see any harm in users giving those information but we should
have some checks to ensure that the server is in standby mode and is
running locally. The other related point is do we need to take input
for the target cluster directory from the user? Can't we fetch that
information once we are connected to standby?

>
> 05.
> I found that the connection string for each subscriptions have a setting
> "fallback_application_name=pg_subscriber". Can we remove it?
>
> ```
> postgres=# SELECT subconninfo FROM pg_subscription;
>                                    subconninfo
> ---------------------------------------------------------------------------------
>  user=postgres port=5431 fallback_application_name=pg_subscriber dbname=postgres
> (1 row)
> ```

Can that help distinguish the pg_subscriber connection on the publisher?


--
With Regards,
Amit Kapila.