Обсуждение: pgsql: Allow some recovery parameters to be changed with reload

Поиск
Список
Период
Сортировка

pgsql: Allow some recovery parameters to be changed with reload

От
Peter Eisentraut
Дата:
Allow some recovery parameters to be changed with reload

Change

archive_cleanup_command
promote_trigger_file
recovery_end_command
recovery_min_apply_delay

from PGC_POSTMASTER to PGC_SIGHUP.  This did not require any further
changes.

Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://www.postgresql.org/message-id/flat/ca28011a-cfaa-565c-d622-c1907c33ecf7%402ndquadrant.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/13b89f96d07ad3da67b57f66c134c3609bd3e98f

Modified Files
--------------
doc/src/sgml/config.sgml                      | 21 +++++++++++++++++----
src/backend/utils/misc/guc.c                  |  8 ++++----
src/backend/utils/misc/postgresql.conf.sample |  4 ----
3 files changed, 21 insertions(+), 12 deletions(-)


Re: pgsql: Allow some recovery parameters to be changed with reload

От
Michael Paquier
Дата:
On Thu, Feb 07, 2019 at 07:52:13AM +0000, Peter Eisentraut wrote:
> Allow some recovery parameters to be changed with reload
>
> Change
>
> archive_cleanup_command
> promote_trigger_file
> recovery_end_command
> recovery_min_apply_delay
>
> from PGC_POSTMASTER to PGC_SIGHUP.  This did not require any further
> changes.

The timestamp of this commit is a bit messed up:
commit: 13b89f96d07ad3da67b57f66c134c3609bd3e98f
author: Peter Eisentraut <peter@eisentraut.org>
date: Mon, 4 Feb 2019 09:28:17 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date: Thu, 7 Feb 2019 08:34:48 +0100

Perhaps you overlooked a --reset-author switch?
--
Michael

Вложения

Re: pgsql: Allow some recovery parameters to be changed with reload

От
Alvaro Herrera
Дата:
On 2019-Feb-08, Michael Paquier wrote:

> The timestamp of this commit is a bit messed up:
> commit: 13b89f96d07ad3da67b57f66c134c3609bd3e98f
> author: Peter Eisentraut <peter@eisentraut.org>
> date: Mon, 4 Feb 2019 09:28:17 +0100
> committer: Peter Eisentraut <peter@eisentraut.org>
> date: Thu, 7 Feb 2019 08:34:48 +0100
> 
> Perhaps you overlooked a --reset-author switch?

I don't think we actually have a rule about these timestamps, and I
don't think we really care, do we?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Re: pgsql: Allow some recovery parameters to be changed with reload

От
Peter Eisentraut
Дата:
On 08/02/2019 08:45, Michael Paquier wrote:
> The timestamp of this commit is a bit messed up:

Where you say "a bit messed up" one might also say "accurately
reflecting history". :)

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Re: pgsql: Allow some recovery parameters to be changed with reload

От
Tom Lane
Дата:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Feb-08, Michael Paquier wrote:
>> The timestamp of this commit is a bit messed up:
>> commit: 13b89f96d07ad3da67b57f66c134c3609bd3e98f
>> author: Peter Eisentraut <peter@eisentraut.org>
>> date: Mon, 4 Feb 2019 09:28:17 +0100
>> committer: Peter Eisentraut <peter@eisentraut.org>
>> date: Thu, 7 Feb 2019 08:34:48 +0100
>> 
>> Perhaps you overlooked a --reset-author switch?

> I don't think we actually have a rule about these timestamps, and I
> don't think we really care, do we?

Yeah, if you want to see a sequence of dates that makes sense,
you need to look at the commit-date.  Whether the author-date
closely matches that depends on the particular committer's
workflow.

            regards, tom lane


Re: pgsql: Allow some recovery parameters to be changed with reload

От
Stephen Frost
Дата:
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > On 2019-Feb-08, Michael Paquier wrote:
> >> The timestamp of this commit is a bit messed up:
> >> commit: 13b89f96d07ad3da67b57f66c134c3609bd3e98f
> >> author: Peter Eisentraut <peter@eisentraut.org>
> >> date: Mon, 4 Feb 2019 09:28:17 +0100
> >> committer: Peter Eisentraut <peter@eisentraut.org>
> >> date: Thu, 7 Feb 2019 08:34:48 +0100
> >>
> >> Perhaps you overlooked a --reset-author switch?
>
> > I don't think we actually have a rule about these timestamps, and I
> > don't think we really care, do we?
>
> Yeah, if you want to see a sequence of dates that makes sense,
> you need to look at the commit-date.  Whether the author-date
> closely matches that depends on the particular committer's
> workflow.

While I agree that we don't really have a formal policy, there are
certainly some who do (or, at least did) seem to care quite a bit about
this and that's why I've been using '--ignore-date' for quite some time
in my workflow:

https://www.postgresql.org/message-id/CA%2BTgmobEgs1%3DAT0_SRvf6K9XrG7QAUyRNeuv5D9oaXrmpST9fw%40mail.gmail.com

Thanks!

Stephen

Вложения

Re: pgsql: Allow some recovery parameters to be changed with reload

От
Michael Paquier
Дата:
On Sat, Feb 09, 2019 at 01:35:52PM -0500, Stephen Frost wrote:
> While I agree that we don't really have a formal policy, there are
> certainly some who do (or, at least did) seem to care quite a bit about
> this and that's why I've been using '--ignore-date' for quite some time
> in my workflow:
>
> https://www.postgresql.org/message-id/CA%2BTgmobEgs1%3DAT0_SRvf6K9XrG7QAUyRNeuv5D9oaXrmpST9fw%40mail.gmail.com

I have messed up that one time in the last and I have noticed that
folks care about that, so I try to be careful and I use
--reset-author.  Now one reason why I got confused is that I had this
git alias to show a simple graph of the git commits:
-   graph = log --graph --date-order -C -M --pretty=format:\"<%h> %ad [%an] %Cgreen%d%Creset %s\" --all --date=short
+   graph = log --graph --date-order -C -M --pretty=format:\"<%h> %cd [%cn] %Cgreen%d%Creset %s\" --all --date=short

%ad and %an stand respectively for the author date and the author
name, and moving to %cd and $cn for the commit date and the committer
name is one way to improve things.
--
Michael

Вложения