Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog |
Дата | |
Msg-id | CAB7nPqSFDQP6sRfxHzY+_pEdB5=81dNUX1aB_JLGnOLxdcbJzQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Automatic cleanup of oldest WAL segments withpg_receivexlog (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: [HACKERS] Automatic cleanup of oldest WAL segments withpg_receivexlog
|
Список | pgsql-hackers |
On Fri, Feb 24, 2017 at 11:56 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > On 2/23/17 8:47 PM, Michael Paquier wrote: >> >> Anything else than measured in bytes either requires a lookup at the >> file timestamp, which is not reliable with noatime or a lookup at WAL >> itself to decide when is the commit timestamp that matches the oldest >> point in time of the backup policy. > > An indication that it'd be nice to have a better way to store this > information as part of a base backup, or the archived WAL files. 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. >> 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. -- Michael
В списке pgsql-hackers по дате отправления: