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
In response to
pgsql-hackers by date
|Next:||From: Hannu Krosing||Date: 2010-04-28 15:46:44|
|Subject: Re: Differential backup|
|Previous:||From: Tom Lane||Date: 2010-04-28 15:32:25|
|Subject: Re: pg_start_backup and pg_stop_backup Re: Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct |