Re: [Patch] add new parameter to pg_replication_origin_session_setup
От | Doruk Yilmaz |
---|---|
Тема | Re: [Patch] add new parameter to pg_replication_origin_session_setup |
Дата | |
Msg-id | CAMPB6wdtKZLEeZ7UW=DYmXWv8Y=uVGrDqXTMhT19Z4VTzo3cfg@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: [Patch] add new parameter to pg_replication_origin_session_setup ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
Re: [Patch] add new parameter to pg_replication_origin_session_setup
|
Список | 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 по дате отправления: