Hi,
On 6/26/23 12:34 PM, Amit Kapila wrote:
On Mon, Jun 26, 2023 at 11:15 AM Drouvot, Bertrand
<bertranddrouvot...@gmail.com> wrote:
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?
That also may not be sufficient because as soon as the slot is
invalidated/dropped, the required WAL could be removed on standby.
Yeah, I think once the slot is dropped we just have to wait for the slot to
be re-created on the standby according to the new synchronize_slot_names GUC.
Assuming the initial slot "creation" on the standby (coming from the
synchronize_slot_names usage)
is working "correctly" then it should also work "correctly" once the slot is
dropped.
If we agree that a synchronized slot can not/should not be consumed (will
implement this behavior) then
I think the proposed scenario above should make sense, do you agree?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
