Re: [Patch] add new parameter to pg_replication_origin_session_setup - Mailing list pgsql-hackers

From Doruk Yilmaz
Subject Re: [Patch] add new parameter to pg_replication_origin_session_setup
Date
Msg-id CAMPB6wdtKZLEeZ7UW=DYmXWv8Y=uVGrDqXTMhT19Z4VTzo3cfg@mail.gmail.com
Whole thread Raw
In response to RE: [Patch] add new parameter to pg_replication_origin_session_setup  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Responses Re: [Patch] add new parameter to pg_replication_origin_session_setup
List pgsql-hackers
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.
If you want, I can also make the pg_proc.dat explicit.

Thanks,
Doruk Yılmaz



pgsql-hackers by date:

Previous
From: Ashutosh Sharma
Date:
Subject: Re: How can end users know the cause of LR slot sync delays?
Next
From: Peter Eisentraut
Date:
Subject: Re: Remove traces of long in dynahash.c