Skip to content

Commit a3f72d6

Browse files
robertmhaashackorum
authored andcommitted
Always show an invalidated replication slot as "lost".
Previously, pg_get_replication_slots() would show "lost" for a slot if either (1) the WAL it was using was thought to have been removed or (2) the slot had been invalidated. However, if the slot was still connected, it would instead show "unreserved" in these cases, which is possibly appropriate for case (1) because, due to a race condition, the diagnosis of "lost" might not be accurate, but is not appropriate for case (2), because slot invalidation is not reversible. Once a slot is invalidated, it is ignored for purposes of deciding how much WAL to reserve and for purposes of hot_standby_feedback, so it's important to be clear about which slots are actually being taken into consideration. In newer releases, this is more clear, because the view also shows the reason for the slot being invalidated -- but calling the state of an invalidated slot "unreserved" seems like a bad idea even if the cause is also shown. In older releases, the confusion is much worse, because there's no clear indication that the slot is invalidated. This problem dates to commit b8fd4e0, whose interaction with 4ae08cd most likely wasn't fully understood. Diagnosed-by: Nitin Chobisa <nitin.chobisa@enterprisedb.com> Diagnosed-by: Pavan Deolasee <pavan.deolasee@gmail.com> Diagnosed-by: Robert Haas <rhaas@postgresql.org> Author: Robert Haas <rhaas@postgresql.org>
1 parent 086f6f1 commit a3f72d6

1 file changed

Lines changed: 9 additions & 1 deletion

File tree

src/backend/replication/slotfuncs.c

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -385,8 +385,16 @@ pg_get_replication_slots(PG_FUNCTION_ARGS)
385385
* still alive, then "unreserved" seems more appropriate.
386386
*
387387
* If we do change it, save the state for safe_wal_size below.
388+
*
389+
* As an exception to the above, if the slot has actually been
390+
* invalidated, we always want the state to be reported as
391+
* "lost". Invalidated slots are ignored by code such as
392+
* ReplicationSlotsComputeRequiredXmin and
393+
* ReplicationSlotsComputeLogicalRestartLSN, so calling them
394+
* merely "unreserved" seems wrong.
388395
*/
389-
if (XLogRecPtrIsValid(slot_contents.data.restart_lsn))
396+
if (slot_contents.data.invalidated == RS_INVAL_NONE &&
397+
XLogRecPtrIsValid(slot_contents.data.restart_lsn))
390398
{
391399
ProcNumber procno;
392400

0 commit comments

Comments
 (0)