Re: [HACKERS] Automatic cleanup of oldest WAL segments withpg_receivexlog

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [HACKERS] Automatic cleanup of oldest WAL segments withpg_receivexlog
Дата
Msg-id 5bcc005c-baf1-8909-bab8-054af9e3b0ad@BlueTreble.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On 2/23/17 9:01 PM, Michael Paquier wrote:
> An idea here would be to add in the long header of the segment a
> timestamp of when it was created. This is inherent to only the server
> generating the WAL.

ISTM it'd be reasonable (maybe even wise) for WAL files to contain info 
about the first and last LSN, commit xid, timestamps, etc.

>>> That could be made performance
>>> wise with an archive command. With pg_receivexlog you could make use
>>> of the end-segment command to scan the completely written segment for
>>> this data before moving on to the next one. At least it gives an
>>> argument for having such a command. David Steele mentioned that he
>>> could make use of such a thing.
>> BTW, I'm not opposed to an end-segment command; I'm just saying I don't
>> think having it would really help users very much.
> Thanks. Yes that's hard to come up here with something that would
> satisfy enough users without giving much maintenance penalty.

Yeah, I think it'd be a decent (though hopefully not huge) amount of work.

As I see it, we got away for years with no replication, but eventually 
realized that we were really leaving a hole in our capabilities by not 
having built-in binary rep. I think we're nearing a similar point with 
handling PITR backups. People have written some great tools to help with 
this, but at some point (PG 11? 13?) there should probably be some 
strong included tools.

I suspect that a huge improvement on the internal tools could be had for 
1/2 or less the effort that's been spent on all the external ones. Of 
course, much of that is because the external tools have helped prove out 
what works and what doesn't.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: [HACKERS] Idea on how to simplify comparing two sets
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] GUC for cleanup indexes threshold.