Hi,
On 6/20/23 12:22 PM, Amit Kapila wrote:
On Mon, Jun 19, 2023 at 9:56 PM Drouvot, Bertrand
<bertranddrouvot...@gmail.com> wrote:
In such a case (slot valid on the primary but invalidated on the standby) then
I think we
could drop and recreate the invalidated slot on the standby.
Will it be safe? Because after recreating the slot, it will reserve
the new WAL location and build the snapshot based on that which might
miss some important information in the snapshot. For example, to
update the slot's position with new information from the primary, the
patch uses pg_logical_replication_slot_advance() which means it will
process all records and update the snapshot via
DecodeCommit->SnapBuildCommitTxn().
Your concern is that the slot could have been consumed on the standby?
I mean, if we suppose the "synchronized" slot can't be consumed on the standby
then
drop/recreate such an invalidated slot would be ok?
Asking, because I'm not sure we should allow consumption of a "synchronized" slot
until the standby gets promoted.
When the patch has been initially proposed, logical decoding from a standby
was not implemented yet.
The other related thing is that do we somehow need to ensure that WAL
is replayed on standby before moving the slot's position to the target
location received from the primary?
Yeah, will check if this is currently done that way in the patch proposal.
BTW, does the patch handles drop of logical slots on standby when the
same slot is dropped on publisher/primary?
from what I've seen, yes it looks like it behaves that way (will look closer).
Okay, I have asked because I don't see a call to ReplicationSlotDrop()
in the patch.
Right. I'd need to look closer to understand how it works (for the moment
the "only" thing I've done was the re-base shared up-thread).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
