Re: [Patch] add new parameter to pg_replication_origin_session_setup

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Doruk Yilmaz <doruk(at)mixrank(dot)com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [Patch] add new parameter to pg_replication_origin_session_setup
Date: 2025-09-06 05:09:48
Message-ID: CAA4eK1LHVd8wQzauWgeEV436L7btrCfujPH1sR196sY_Mp8zYA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 3, 2025 at 6:13 PM Doruk Yilmaz <doruk(at)mixrank(dot)com> wrote:
>
> 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?
>
> Actually, it's a bit simpler than that - there are no two connections.
> Our program reads changes from JSONL files rather than directly from a
> publisher connection.
> We have multiple Python processes, each with a single database
> connection to the subscriber,
> reading from these files and applying changes in parallel.
>
> > Is there a rule which attribute is clarified and others are not?
> > For example, VOLATILE is specified on both side, STRICT is written only in the
> > system_functions.sql, and PARALLEL UNSAFE is set on pg_proc.dat.
>
> In pg_proc.dat, I believe the STRICT, IMMUTABLE, and PARALLEL SAFE are
> the defaults (check out pg_proc.h).
> So in pg_proc.dat, the ones that are specified are the ones that
> aren't defaults,
> there is provolatile => 'v' (for VOLATILE) and proparallel => 'u' (for
> UNSAFE), but no prostrict since it's already true by default.
> In system_functions.sql, I went with being explicit about all the
> attributes for clarity as it is the code declaration.
>

Then why didn't you specified PARALLEL UNSAFE as well?

BTW, yesterday a new thread started with the same requirement [1]. It
uses a slightly different way to define the new function. do you have
any opinion on it?

[1] - https://www.postgresql.org/message-id/CAE2gYzyTSNvHY1%2BiWUwykaLETSuAZsCWyryokjP6rG46ZvRgQA%40mail.gmail.com
--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-09-06 05:16:05 Re: How can end users know the cause of LR slot sync delays?
Previous Message Dilip Kumar 2025-09-06 05:03:30 Re: Parallel Apply