From: | Sergei Kornilov <sk(at)zsrv(dot)org> |
---|---|
To: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | recovery_target_action=pause with confusing hint |
Date: | 2020-01-30 11:00:43 |
Message-ID: | 19168211580382043@myt5-b646bde4b8f3.qloud-c.yandex.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello
Currently during point-in-time recovery with recovery_target_action = 'pause' we print log lines:
> LOG: recovery has paused
> HINT: Execute pg_wal_replay_resume() to continue.
My colleague told me that this is a terrible moment: to continue what exactly? It sounds like "to continue replay", similar to normal pg_wal_replay_pause/pg_wal_replay_resume behavior. We have just small note in documentation:
> The paused state can be resumed by using pg_wal_replay_resume() (see Table 9.81), which then causes recovery to end.
But I think this is important place and can be improved.
Also the database does not respond to the promote signals at this stage. Attached patch 0001 with the test will fail.
0002 patch contains my proposed ideas:
- introduce separate message for pause due pg_wal_replay_pause call and for recovery_target_action.
- check for standby triggers only for recovery_target_action - I am not sure this would be safe for pg_wal_replay_pause() call case
Maybe more verbose hint would be appropriate:
> Execute pg_promote() to end recovery or shut down the server, change the recovery target settings to a later target and restart to continue recovery
Thoughts?
regards, Sergei
Attachment | Content-Type | Size |
---|---|---|
0002-improve-recovery-target-action-behavior.patch | text/x-diff | 2.3 KB |
0001-test-promote-while-recovery-target-action-pause.patch | text/x-diff | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Sehrope Sarkuni | 2020-01-30 11:35:51 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Previous Message | Amit Kapila | 2020-01-30 10:41:44 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |