Re: [Patch] add new parameter to pg_replication_origin_session_setup
От | Amit Kapila |
---|---|
Тема | Re: [Patch] add new parameter to pg_replication_origin_session_setup |
Дата | |
Msg-id | CAA4eK1LHVd8wQzauWgeEV436L7btrCfujPH1sR196sY_Mp8zYA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Patch] add new parameter to pg_replication_origin_session_setup (Doruk Yilmaz <doruk@mixrank.com>) |
Ответы |
Re: [Patch] add new parameter to pg_replication_origin_session_setup
|
Список | pgsql-hackers |
On Wed, Sep 3, 2025 at 6:13 PM Doruk Yilmaz <doruk@mixrank.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.
В списке pgsql-hackers по дате отправления: