Magnus Hagander <mag...@hagander.net> writes: > Attached is an updated streaming base backup patch, based off the work
Thanks! :) > * Compression: Do we want to be able to compress the backups server-side? Or > defer that to whenever we get compression in libpq? (you can still tunnel it > through for example SSH to get compression if you want to) My thinking is > defer it. Compression in libpq would be a nice way to solve it, later. > * Compression: We could still implement compression of the tar files in > pg_streamrecv (probably easier, possibly more useful?) What about pg_streamrecv | gzip > …, which has the big advantage of being friendly to *any* compression command line tool, whatever patents and licenses? > * Stefan mentiond it might be useful to put some > posix_fadvise(POSIX_FADV_DONTNEED) > in the process that streams all the files out. Seems useful, as long as that > doesn't kick them out of the cache *completely*, for other backends as well. > Do we know if that is the case? Maybe have a look at pgfincore to only tag DONTNEED for blocks that are not already in SHM? > * include all the necessary WAL files in the backup. This way we could > generate > a tar file that would work on it's own - right now, you still need to set up > log archiving (or use streaming repl) to get the remaining logfiles from the > master. This is fine for replication setups, but not for backups. > This would also require us to block recycling of WAL files during the > backup, > of course. Well, I would guess that if you're streaming the WAL files in parallel while the base backup is taken, then you're able to have it all without archiving setup, and the server could still recycling them. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
