Re: Fetching timeline during recovery
От | Jehan-Guillaume de Rorthais |
---|---|
Тема | Re: Fetching timeline during recovery |
Дата | |
Msg-id | 20190725193808.1648ddc8@firost обсуждение исходный текст |
Ответ на | Re: Fetching timeline during recovery (Jehan-Guillaume de Rorthais <jgdr@dalibo.com>) |
Ответы |
Re: Fetching timeline during recovery
|
Список | pgsql-hackers |
Hello, On Wed, 24 Jul 2019 14:33:27 +0200 Jehan-Guillaume de Rorthais <jgdr@dalibo.com> wrote: > On Wed, 24 Jul 2019 09:49:05 +0900 > Michael Paquier <michael@paquier.xyz> wrote: > > > On Tue, Jul 23, 2019 at 06:05:18PM +0200, Jehan-Guillaume de Rorthais > > wrote: [...] > > I think that there are arguments for being more flexible with it, and > > perhaps have a system-level view to be able to look at some of its fields. > > Great idea. I'll give it a try to keep the discussion on. After some thinking, I did not find enough data to expose to justify the creation a system-level view. As I just need the current timeline I wrote "pg_current_timeline()". Please, find the patch in attachment. The current behavior is quite simple: * if the cluster is in production, return ThisTimeLineID * else return walrcv->receivedTLI (using GetWalRcvWriteRecPtr) This is really naive implementation. We should probably add some code around the startup process to gather and share general recovery stats. This would allow to fetch eg. the current recovery method, latest xlog file name restored from archives or streaming, its timeline, etc. Any thoughts? Regards,
Вложения
В списке pgsql-hackers по дате отправления: