On Tue, Mar 17, 2020 at 11:39:11PM +0300, Sergei Kornilov wrote:
> We need this change to set is_temp_slot properly. PrimarySlotName
> GUC can usually be an empty string, so just "slotname != NULL" is
> not enough.
Yep, or a temporary slot would never be created even if there is no
slot defined, a
Hello
> I have reworked that part, adding more comments about the use of GUC
> parameters when establishing the connection to the primary for a WAL
> receiver. And also I have added an extra comment to walreceiver.c
> about the use of GUcs in general, to avoid this stuff again in the
> future. The
On Mon, Feb 17, 2020 at 04:57:04PM +0300, Sergei Kornilov wrote:
> Thank you, here is updated patch
Thanks
> I changed this comments because they describes behavior during
> change value of wal_receiver_create_temp_slot. But yes, I need to
> add some comments to RequestXLogStreaming.
I have rew
Hello
> Thanks for posting this patch, Sergei. Here is a review to make
> things move on.
Thank you, here is updated patch
> The set of comments you are removing from walreceiver.c to decide if a
> temporary slot needs to be created or not should be moved to
> walreceiverfuncs.c as you move the
On Wed, Jan 22, 2020 at 06:58:46PM +0300, Sergei Kornilov wrote:
> I would like to cross-post here a patch with such changes that I posted in
> "allow online change primary_conninfo" thread.
> This thread is more appropriate for discussion about
> wal_receiver_create_temp_slot.
>
> PS: I posted
On Mon, Feb 10, 2020 at 01:46:04PM -0800, Andres Freund wrote:
> I still architecturally don't find it attractive that the active
> configuration between walreceiver and startup process can diverge
> though. Imagine if we e.g. added the ability to receive WAL over
> multiple connections from one ho
Hi,
On 2020-02-10 16:46:04 +0100, Peter Eisentraut wrote:
> On 2020-01-22 06:55, Michael Paquier wrote:
> > In the thread about switching primary_conninfo to be reloadable, we
> > have argued at great lengths that we should never have the WAL
> > receiver fetch by itself the GUC parameters used fo
On 2020-01-22 06:55, Michael Paquier wrote:
In the thread about switching primary_conninfo to be reloadable, we
have argued at great lengths that we should never have the WAL
receiver fetch by itself the GUC parameters used for the connection
with its primary. Here is the main area of the discus
Hello
> In short, the following things:
> - wal_receiver_create_temp_slot should be made PGC_POSTMASTER,
> similarly to primary_slot_name and primary_conninfo.
> - WalReceiverMain() should not load the parameter from the GUC context
> by itself.
> - RequestXLogStreaming(), called by the startup pr
Hi Peter,
(Adding Andres and Sergei in CC.)
On Tue, Jan 14, 2020 at 01:57:34PM +, Peter Eisentraut wrote:
> walreceiver uses a temporary replication slot by default
>
> If no permanent replication slot is configured using
> primary_slot_name, the walreceiver now creates and uses a temporary
>
10 matches
Mail list logo
