This is too implicit that recovery.signal will be removed
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/runtime-config-wal.html Description: Hello. On the page https://www.postgresql.org/docs/current/runtime-config-wal.html Actual: >To start the server in targeted recovery mode, create a file called recovery.signal in the data directory. If both standby.signal and recovery.signal files are created, standby mode takes precedence. Targeted recovery mode ends when the archived WAL is fully replayed, or when recovery_target is reached. In this mode, the parameters from both this section and Section 20.5.6 will be used. Expected: >To start the server in targeted recovery mode, create a file called recovery.signal in the data directory. If both standby.signal and recovery.signal files are created, standby mode takes precedence. Targeted recovery mode ends and recovery.signal file is removed when the archived WAL is fully replayed, or when recovery_target is reached. In this mode, the parameters from both this section and Section 20.5.6 will be used. File 'recovery.signal' is not removed when `recovery_target_action` is *shutdown*. Overall I did not find page where I can read about all types of *.signal files and how to deal with them.
Re: This is too implicit that recovery.signal will be removed
Only here I found explicit mention that recovery.signal will be removed: https://www.postgresql.org/docs/16/continuous-archiving.html#BACKUP-PITR-RECOVERY see p8. On Thu, Oct 5, 2023 at 10:06 AM PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/runtime-config-wal.html > Description: > > Hello. > On the page > https://www.postgresql.org/docs/current/runtime-config-wal.html > Actual: > >To start the server in targeted recovery mode, create a file called > recovery.signal in the data directory. If both standby.signal and > recovery.signal files are created, standby mode takes precedence. Targeted > recovery mode ends when the archived WAL is fully replayed, or when > recovery_target is reached. In this mode, the parameters from both this > section and Section 20.5.6 will be used. > > Expected: > >To start the server in targeted recovery mode, create a file called > recovery.signal in the data directory. If both standby.signal and > recovery.signal files are created, standby mode takes precedence. Targeted > recovery mode ends and recovery.signal file is removed when the archived WAL > is fully replayed, or when recovery_target is reached. In this mode, the > parameters from both this section and Section 20.5.6 will be used. File > 'recovery.signal' is not removed when `recovery_target_action` is > *shutdown*. > > Overall I did not find page where I can read about all types of *.signal > files and how to deal with them.
Re: This is too implicit that recovery.signal will be removed
On Thu, Oct 5, 2023 at 8:15 AM PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/runtime-config-wal.html > Description: > > Hello. > On the page > https://www.postgresql.org/docs/current/runtime-config-wal.html > Actual: > >To start the server in targeted recovery mode, create a file called > recovery.signal in the data directory. If both standby.signal and > recovery.signal files are created, standby mode takes precedence. Targeted > recovery mode ends when the archived WAL is fully replayed, or when > recovery_target is reached. In this mode, the parameters from both this > section and Section 20.5.6 will be used. > > Expected: > >To start the server in targeted recovery mode, create a file called > recovery.signal in the data directory. If both standby.signal and > recovery.signal files are created, standby mode takes precedence. Targeted > recovery mode ends and recovery.signal file is removed when the archived > WAL > is fully replayed, or when recovery_target is reached. In this mode, the > parameters from both this section and Section 20.5.6 will be used. File > 'recovery.signal' is not removed when `recovery_target_action` is > *shutdown*. > > Except that doesn't seem to be true since "pause" is the default action. We probably should add instead: Targeted recovery mode ends when the archived WAL is fully replayed, or when recovery_target is reached. The server is left in the state corresponding to the recovery_target_action setting. David J.
Re: Unclear guarantees about sort order on https://www.postgresql.org/docs/current/queries-order.html
On Wed, Oct 4, 2023 at 6:37 PM Erik Wienhold wrote: > On 2023-10-04 16:24 +0200, PG Doc comments form write: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/16/queries-order.html > > Description: > > > > The document only says this about unsorted queries: > > > > > After a query has produced an output table (after the select list has > been > > > processed) it can optionally be sorted. If sorting is not chosen, the > rows > > > will be returned in an unspecified order. The actual order in that > case will > > > depend on the scan and join plan types and the order on disk, but it > must > > > not be relied on. A particular output ordering can only be guaranteed > if the > > > sort step is explicitly chosen. > > > > It mentions "If sorting is not chosen". This sort of implies that if you > > pick a sort the output order is predictable. However I believe that the > only > > actual guarantee is if the sort columns selected produce a unique value. > > > > For example if you do `ORDER BY name` and have two rows with the same > name I > > don't think the order of those rows is predictable. > > "The relative ordering of two rows that are not distinct with respect to > the is implementation-dependent." > The OP is assuming a promise of a deterministic ordering of all output rows and such a promise is only possible if the order by clause columns uniquely identify every row in the output. This is because all the order by promises is that output ordering will conform to the order by specification, and indeed if it is under-specified such that multiple rows match a given bin, then there is no deterministic relative ordering among those rows. I don't feel that the wording makes any such inference regarding determinism of row output due to the mere presence of an order by clause. Nor doesn't such determinism in the face of an under-specific clause even make logical sense. I'm mostly inclined to leave the wording alone given this single report. My only complaints are style-istic at this point. That said, maybe a final sentence: Assuming every output row can be uniquely identified by some subset of the output columns, that subset must all be listed within the order by clause if you wish to ensure a fully deterministic ordering. David J.
It is not clear from documentation when and how I should restore base backup
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/16/continuous-archiving.html Description: Hello. On page: https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-PITR-RECOVERY Is is not clear should I do additional actions to restore basebackup first and then WAL files (as described at p6) This paragraph even more confusing: https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-STANDALONE > ... and no special action is required to restore the backup. Should I configure restore_command at least? Thank you.
Re: It is not clear from documentation when and how I should restore base backup
On Thu, Oct 5, 2023, 11:11 PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/16/continuous-archiving.html > Description: > > Hello. > > On page: > > https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-PITR-RECOVERY > Is is not clear should I do additional actions to restore basebackup first > and then WAL files (as described at p6) > You mean step 4? > This paragraph even more confusing: > > https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-STANDALONE > > ... and no special action is required to restore the backup. > Should I configure restore_command at least? > It is standalone, everything needed and possible exists in the backup file pg_basebackup created. David J.
