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 по дате отправления: