Dear Hayato,
Thanks for the feedback on the patch, I'm glad the latest version looks good.
I was wondering if there is anything else I need to do on my end, or
any other process I should be aware of, for this patch to move
forward? I'm happy to make any further adjustments or provide more
informat
> Then why didn't you specified PARALLEL UNSAFE as well?
You are correct, I missed marking the function as PARALLEL UNSAFE.
I’ve attached a revised patch with the correct annotation.
> BTW, yesterday a new thread started with the same requirement [1]. It
> uses a slightly different way to define
Dear Hayato,
> So, your python process establishes two connections, for publisher
> (replication connection)
> and subscriber (normal connection). It receives changes from the publisher,
> constructs SQL statements from the received results, and sends to subscriber's
> backend, is it right?
Actu
Dear Hayato,
> Can you explain more why we must extend the SQL interface?
In our system the workers aren't background workers and we don't ship
a server-side extension; they're plain external processes (Python in
our case) talking over standard database connections. In many
deployments -especiall
> Your use looks good to me. So, maybe we can update the docs with the
> dangers if the users of API doesn't follow commit order then it may
> lead to data inconsistency should be sufficient. Additionally, we may
> want to give an example as to how to use this API for parallel apply.
That sounds r
On Mon, Aug 11, 2025 at 9:44 AM Amit Kapila wrote:
> How do you advance the origin? Did you use > pg_replication_origin_advance()?
> If so, you should be aware that it
> can be used for initial setup; see comment in that API code...
No, we don't use pg_replication_origin_advance(). We use
pg_rep
On Mon, Jul 29, 2025 at 8:13 AM Amit Kapila wrote:
> That is true but I still feel there has to be some mechanism where we
> can catch and give an ERROR to the user, if it doesn't follow the
> same. For example, pg_replication_origin_advance() always allows going
> backwards in terms of LSN which
On Mon, Mar 3, 2025 at 6:39 AM Amit Kapila wrote:
>
> To use replication_origin by multiple processes, one must maintain the
> commit order as we do internally by allowing the leader process to
> wait for the parallel worker to finish the commit. See comments atop
> replorigin_session_setup(). Now
I noticed that the patch needs rebasing, so here is the rebased version.
Hopefully it makes to the commitfest.
Doruk Yılmaz
From 74a74fd02bce786093c19a23bef9444d0b8ef41d Mon Sep 17 00:00:00 2001
From: Doruk
Date: Thu, 15 Aug 2024 23:34:26 +0300
Subject: [PATCH v4] pg_replication_origin_session_se
Hello again,
On Tue, Aug 13, 2024 at 12:48 AM Euler Taveira wrote:
> I'm curious about your use case. Is it just because the internal function has
> a
> different signature or your tool is capable of apply logical replication
> changes
> in parallel using the SQL API?
The latter is correct, it
Hello all,
While working on our internal tools that utilise replication, we
realised that a new parameter was added to the internal C function
corresponding to pg_replication_origin_session_setup.
However this parameter wasn't included in the user-facing API [1].
In 'src/backend/replication/logica
11 matches
Mail list logo
