aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorAlexander Korotkov <akorotkov@postgresql.org>2024-10-24 14:38:27 +0300
committerAlexander Korotkov <akorotkov@postgresql.org>2024-10-24 14:38:27 +0300
commit73da6b8d1b3e8b7541961c3534e584243cb0470e (patch)
tree586206c3c5cda81c49b05be18357066d30bb09a8 /doc/src
parent6cfebfe88b9a753152862b83d42d1103125b01bd (diff)
downloadpostgresql-73da6b8d1b3e8b7541961c3534e584243cb0470e.tar.gz
postgresql-73da6b8d1b3e8b7541961c3534e584243cb0470e.zip
Refactor WaitForLSNReplay() to return the result of waiting
Currently, WaitForLSNReplay() immediately throws an error if waiting for LSN replay is not successful. This commit teaches WaitForLSNReplay() to return the result of waiting, while making pg_wal_replay_wait() responsible for throwing an appropriate error. This is preparation to adding 'no_error' argument to pg_wal_replay_wait() and new function pg_wal_replay_wait_status(), which returns the last wait result status. Additionally, we stop distinguishing situations when we find our instance to be not in a recovery state before entering the waiting loop and inside the waiting loop. Standby promotion may happen at any moment, even between issuing a procedure call statement and pg_wal_replay_wait() doing a first check of recovery status. Thus, there is no pointing distinguishing these situations. Also, since we may exit the waiting loop and see our instance not in recovery without throwing an error, we need to deleteLSNWaiter() in that case. We do this unconditionally for the sake of simplicity, even if standby was already promoted after reaching the target LSN, the startup process surely already deleted us. Reported-by: Michael Paquier Discussion: https://postgr.es/m/ZtUF17gF0pNpwZDI%40paquier.xyz Reviewed-by: Michael Paquier, Pavel Borisov
Diffstat (limited to 'doc/src')
0 files changed, 0 insertions, 0 deletions