Dear Shawn, > We operate a fleet of PostgreSQL instances with logical replication. On > several > occasions, we have experienced production incidents where logical decoding > spill > files (pg_replslot/<slot>/xid-*.spill) grew uncontrollably — consuming tens of > gigabytes and eventually filling up the data disk. This caused the entire > instance > to go read-only, impacting not just replication but all write workloads.
We have provided the subscription option streaming=parallel since PG16. It replicates on-going transactions and applies immediately. Does it avoid the issue? > 5. Behavior on limit exceeded: An ERROR is raised with > ERRCODE_CONFIGURATION_LIMIT_EXCEEDED. > The walsender exits, but the slot's restart_lsn and confirmed_flush are > preserved. > The subscriber can reconnect after the DBA: Not sure, but doesn't it mean the error is repeating till the GUC is increased? Also, is there any difference for the slots's behavior, with the normal walsender's exit case? Best regards, Hayato Kuroda FUJITSU LIMITED
