Re: could recovery_target_timeline=latest be the default in standby mode?

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: David Steele <david(at)pgmasters(dot)net>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Sergei Kornilov <sk(at)zsrv(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: could recovery_target_timeline=latest be the default in standby mode?
Date: 2018-12-27 23:15:14
Message-ID: 20181227231514.GD2196@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 27, 2018 at 06:36:23PM +0200, David Steele wrote:
> I like the idea of defaulting to the latest timeline since this is what you
> want to do most of the time, but I think we'd then need a value for
> following the current timelime, i.e. the one that the backup was taken on
> (which is the current default).
>
> [...]
>
> I would recommend:
>
> 1) Make the default for recovery_target_timeline always be latest.
> 2) Add a new value, current, that replicates the current behavior.

Yes, I was also thinking something among those lines, and the patch is
a bit confusing by linking standby mode with latest timeline. It
seems to me that switching the default value to "latest" at GUC level
would be the way to go, instead of picking up the TLI from the control
file. Introducing a new value which maps to the current empty value
may be useful as well, like "control_file"?
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-12-27 23:25:29 Re: Offline enabling/disabling of data checksums
Previous Message Petr Jelinek 2018-12-27 23:15:10 Re: row filtering for logical replication