On Tue, 2010-04-27 at 14:30 +0100, Simon Riggs wrote: > Thinking about allowing a backup to tell which files have changed in the > database since last backup. This would allow an external utility to copy > away only changed files. > > Now there's a few ways of doing this and many will say this is already > possible using file access times. > > An explicit mechanism where Postgres could authoritatively say which > files have changed would make many feel safer, especially when other > databases also do this. > > We keep track of which files require fsync(), so we could also keep > track of changed files using that same information.
Would it make sense to split this in two , one for DML/"logical changes" (insert, update, delete, truncate) and another for physical, "non-functional", file-level changes (vacuum, setting hint bits, ...) BTW, is the stats-collection reliable enough for this or is it still possible to lose some changes if we did this together with updating info for pg_stat_user_tables/pg_statio_user_tables ? -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
