Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name

From: Sergei Kornilov <sk(at)zsrv(dot)org>
To: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Donald Dong <xdong(at)csumb(dot)edu>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Postgres hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, "simon(at)2ndquadrant(dot)com" <simon(at)2ndquadrant(dot)com>, "ams(at)2ndquadrant(dot)com" <ams(at)2ndquadrant(dot)com>, "masao(dot)fujii(at)gmail(dot)com" <masao(dot)fujii(at)gmail(dot)com>
Subject: Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name
Date: 2019-01-11 22:55:23
Message-ID: 1307661547247323@sas2-857317bd6599.qloud-c.yandex.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

<div>Hello</div><div><br /></div>&gt; pg_ctl reload is executed (or the equivalent),<div>&gt; different backends reload the file at different times.<br />&gt; There are no added TAP tests for the scenario where the values differ between the two processes, no code comments which explain why it's OK</div><div><br /></div><div>But wait, connection string can not be changed via reload, only during cluster start. How it can differs between processes? </div><div><br />regards, Sergei</div>

Attachment Content-Type Size
unknown_filename text/html 492 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-01-11 22:57:01 Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name
Previous Message Alvaro Herrera 2019-01-11 22:39:47 Re: problems with foreign keys on partitioned tables