Re: Synchronizing slots from primary to standby - Mailing list pgsql-hackers

From Drouvot, Bertrand
Subject Re: Synchronizing slots from primary to standby
Date
Msg-id 17aeb17c-73b7-4038-801a-0edbcdf1fb96@gmail.com
Whole thread Raw
In response to Re: Synchronizing slots from primary to standby  (shveta malik <shveta.malik@gmail.com>)
Responses Re: Synchronizing slots from primary to standby
Re: Synchronizing slots from primary to standby
List pgsql-hackers
Hi,

Thanks for all the work that has been done on this feature, and sorry
to have been quiet on it for so long.

On 9/18/23 12:22 PM, shveta malik wrote:
> On Wed, Sep 13, 2023 at 4:48 PM Hayato Kuroda (Fujitsu)
> <kuroda.hayato@fujitsu.com> wrote:
>> Right, but I wanted to know why it is needed. One motivation seemed to know the
>> WAL location of physical standby, but I thought that struct WalSnd.apply could
>> be also used. Is it bad to assume that the physical walsender always exists?
>>
> 
> We do not plan to target this case where physical slot is not created
> between primary and physical-standby in the first draft.  In such a
> case, slot-synchronization will be skipped for the time being. We can
> extend this functionality (if needed) later.
> 

I do think it's needed to extend this functionality. Having physical slot
created sounds like a (too?) strong requirement as:

- It has not been a requirement for Logical decoding on standby so that could sounds weird
to require it for sync slot (while it's not allowed to logical decode from sync slots)

- One could want to limit the WAL space used on the primary

It seems that the "skipping sync as primary_slot_name not set." warning message is emitted
every 10ms, that seems too verbose to me.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: pg_ctl start may return 0 even if the postmaster has been already started on Windows
Next
From: Robert Haas
Date:
Subject: Re: Questions about the new subscription parameter: password_required