Hi,
On 11/9/23 11:54 AM, shveta malik wrote:
PFA v32 patches which has below changes:
Thanks!
7) Added warning for cases where a user-slot with the same name is
already present which slot-sync worker is trying to create. Sync for
such slots is skipped.
I'm seeing assertion and segfault in this case due to ReplicationSlotRelease()
in synchronize_one_slot().
Adding this extra check prior to it:
- ReplicationSlotRelease();
+ if (!(found && s->data.sync_state == SYNCSLOT_STATE_NONE))
+ ReplicationSlotRelease();
make them disappear.
Open Question:
1) Currently I have put drop slot logic for slots with 'sync_state=i'
in slot-sync worker. Do we need to put it somewhere in promotion-logic
as well?
Yeah I think so, because there is a time window when one could "use" the slot
after the promotion and before it is removed. Producing things like:
"
2023-11-09 15:16:50.294 UTC [2580462] LOG: dropped replication slot
"logical_slot2" of dbid 5 as it was not sync-ready
2023-11-09 15:16:50.295 UTC [2580462] LOG: dropped replication slot
"logical_slot3" of dbid 5 as it was not sync-ready
2023-11-09 15:16:50.297 UTC [2580462] LOG: dropped replication slot
"logical_slot4" of dbid 5 as it was not sync-ready
2023-11-09 15:16:50.297 UTC [2580462] ERROR: replication slot "logical_slot5"
is active for PID 2594628
"
After the promotion one was able to use logical_slot5 and now we can now drop
it.
Perhaps in WaitForWALToBecomeAvailable() where we call
XLogShutdownWalRcv after checking 'CheckForStandbyTrigger'. Thoughts?
You mean here?
/*
* Check to see if promotion is requested. Note that we do
* this only after failure, so when you promote, we still
* finish replaying as much as we can from archive and
* pg_wal before failover.
*/
if (StandbyMode && CheckForStandbyTrigger())
{
XLogShutdownWalRcv();
return XLREAD_FAIL;
}
If so, that sounds like a good place to me.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
