From: | Sergei Kornilov <sk(at)zsrv(dot)org> |
---|---|
To: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Continue work on changes to recovery.conf API |
Date: | 2018-06-21 18:46:07 |
Message-ID: | 607741529606767@web3g.yandex.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello all
I would like to continue work on new recovery api proposed in thread [1]. We have some form of consensus but thread has been inactive for a long time and i hope i can help.
I start from last published patch [2] and make some changes:
- updated to current HEAD
- made the patch pass make check-world run
- removed recovery.auto.conf lookup and changed pg_basebackup to append recovery parameters to postgresql.auto.conf in both plain and tar formats
- revert back trigger_file logic, but rename to promote_signal_file. I think here is no reason to make GUC only for directory path with hardcoded file name as was discussed in original thread.
Any feedback is strongly appreciated. Thank you
A brief summary of proposed changes:
- if recovery.conf present during start we report FATAL error about old style config
- recovery mode start if exists file "recovery.signal" in datadir, all old recovery_target_* options are replaced by recovery_target_type and recovery_target_value GUC
- start standby mode - by file "standby.signal"
- if present both - standby wins
- pg_basebackup -R will append primary_conninfo and primary_slot_name to postgresql.auto.conf config
- all new GUC are still PGC_POSTMASTER
PS: i will add an entry to 2018-09 CommitFest when it is become available.
regards, Sergei
[1] https://www.postgresql.org/message-id/flat/CANP8%2BjLO5fmfudbB1b1iw3pTdOK1HBM%3DxMTaRfOa5zpDVcqzew%40mail.gmail.com
[2] https://www.postgresql.org/message-id/CANP8+jJo-LO4xtS7G=iN7PG5o60WeWdKEAn+X+Gnf+RNay5jGQ@mail.gmail.com
From | Date | Subject | |
---|---|---|---|
Next Message | Sergei Kornilov | 2018-06-21 18:48:07 | Re: Continue work on changes to recovery.conf API |
Previous Message | Nico Williams | 2018-06-21 18:43:52 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |