Commit a3f72d6
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
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
385 | 385 | | |
386 | 386 | | |
387 | 387 | | |
| 388 | + | |
| 389 | + | |
| 390 | + | |
| 391 | + | |
| 392 | + | |
| 393 | + | |
| 394 | + | |
388 | 395 | | |
389 | | - | |
| 396 | + | |
| 397 | + | |
390 | 398 | | |
391 | 399 | | |
392 | 400 | | |
| |||
0 commit comments