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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Sergei Kornilov <sk(at)zsrv(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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:57:01
Message-ID: 20190111225701.ac65ibbulh37a5l6@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-01-12 01:55:23 +0300, Sergei Kornilov wrote:
> > pg_ctl reload is executed (or the equivalent),
> > different backends reload the file at different times.
> > 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
>
> But wait, connection string can not be changed via reload, only during cluster
> start. How it can differs between processes?

One of the major reasons for moving recovery parameters from
recovery.conf to GUCs was to make them changable at runtime in the
future.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ami Ganguli 2019-01-11 23:01:18 How to decode the output from pgoutput
Previous Message Sergei Kornilov 2019-01-11 22:55:23 Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name