| From: | "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Ajin Cherian <itsajin(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Subject: | Re: Synchronizing slots from primary to standby |
| Date: | 2023-11-21 07:43:16 |
| Message-ID: | d54b25c1-7478-48f5-b8be-97a33549bfff@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 11/21/23 6:16 AM, Amit Kapila wrote:
> On Mon, Nov 20, 2023 at 6:51 PM Drouvot, Bertrand
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>> As far the 'i' state here, from what I see, it is currently useful for:
>>
>> 1. Cascading standby to not sync slots with state = 'i' from
>> the first standby.
>> 2. Easily report Slots that did not catch up on the primary yet.
>> 3. Avoid inactive slots to block "active" ones creation.
>>
>> So not creating those slots should not be an issue for 1. (sync are
>> not needed on cascading standby as not created on the first standby yet)
>> but is an issue for 2. (unless we provide another way to keep track and report
>> such slots) and 3. (as I think we should still need to reserve WAL).
>>
>> I've a question: we'd still need to reserve WAL for those slots, no?
>>
>> If that's the case and if we don't call ReplicationSlotCreate() then ReplicationSlotReserveWal()
>> would not work as MyReplicationSlot would be NULL.
>>
>
> Yes, we need to reserve WAL to see if we can sync the slot. We are
> currently creating an RS_EPHEMERAL slot and if we don't explicitly
> persist it when we can't sync, then it will be dropped when we do
> ReplicationSlotRelease() at the end of synchronize_one_slot(). So, the
> loss is probably, the next time we again try to sync the slot, we need
> to again create it and may need to wait for newer restart_lsn on
> standby
Yeah, and doing so we'd reduce the time window to give the slot a chance
to catch up (as opposed to create it a single time and maintain an 'i' state).
> which could be avoided if we have the slot in 'i' state from
> the previous run.
Right.
> I don't deny the importance of having 'i'
> (initialized) state but was just trying to say that it has additional
> code complexity.
Right, and I think it's worth it.
> OTOH, having it may give better visibility to even
> users about slots that are not active (say manually created slots on
> the primary).
Agree.
All that being said, on my side I'm +1 on keeping the 'i' state behavior
as it is implemented currently (would be happy to hear others' opinions too).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shveta malik | 2023-11-21 08:26:49 | Re: Synchronizing slots from primary to standby |
| Previous Message | Laurenz Albe | 2023-11-21 07:42:42 | Re: Use of backup_label not noted in log |