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