On 01/15/2014 08:46 AM, Jim Nasby wrote:
On 1/14/14, 7:41 AM, Magnus Hagander wrote:
Yes, it would be necessary to scan the whole database as the LSN
to be
checked is kept in PageHeaderData :). Perhaps it is not that
performant, but my initial thought was that perhaps the amount of
data
necessary to maintain incremental backups could balance with the
amount of WAL necessary to keep and limit the whole amount on disk.
It wouldn't be worse performance wise than a full backup. That one
also has to read all the blocks after all... You're decreasing network
traffic and client storage, with the same I/O on the server side.
Seems worthwhile.
If there's enough demand, it probably wouldn't be that hard to keep a
copy of the page LSNs in a fork; you only need to ensure that the LSN in
the fork must be older than the LSN on disk could possibly be, and you
wouldn't have to update the fork every time.
That's backwards. You need to ensure that the LSN in the fork >= that on
disk. Otherwise the backup will incorrectly conclude that a page doesn't
need to be backed up because it hasn't been modified.
BTW, an incremental backup could possibly be useful as a way to catch a
streaming replica up that's fallen way behind. The write IO would be
sequential instead of trying to random-write while processing each WAL
record.
Yeah. And it would work even if you no longer have all the WAL files
available.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
