Bug that may cause backup a lot of unuseful page.

[movead]

pg_rman/backup.c

Line 1426 in 4abebbe

bool prev_file_not_found = false;

Here code has something wrong,and i add one line code.

static void
backup_files(const char *from_root,
			 const char *to_root,
			 parray *files,
			 parray *prev_files,
			 const XLogRecPtr *lsn,
			 bool compress,
			 const char *prefix)
{
	int				i;
	int				num_skipped = 0;
	struct timeval	tv;
	bool			prev_file_not_found = false;

	/* sort pathname ascending */
	parray_qsort(files, pgFileComparePath);

	gettimeofday(&tv, NULL);

	/* backup a file or create a directory */
	for (i = 0; i < parray_num(files); i++)
	{
		int			ret;
		struct stat	buf;

               pgFile *file = (pgFile *) parray_get(files, i);
               ///////////////////////////////////////////////////////////////////
               //I add code here
               prev_file_not_found = false;
               ...
               ...
               ...
       }

}

If not do this change, it may backup a lot of files which is nothing useful change when a table is more than 100G. It is due to PostgreSQL may change tuple header data without change SLN.

[MoonInsung]

Dear lchch.
Thank you for finding a bug.
I had reproduced the problem in this way.

1. Input 500mb data to table A
2. Input 1mb data to table B
3. Run to full backup
4. Add to 1 gb data to table A
5. Add to 1mb data to table B
6. Run to incremental backup
   -> It works the same as a full backup(2mb), not 1mb data which is incremental data for table B

This problem is that did not initialize the value of bool(prev_file_not_found) as you said.
I'll check if there's any other problem and try to fix the source-code.

Regards.

[movead]

That is the bug.
It is dangerous for table A too because of it's sort.

Example:
Relfilenode of table A is 16384
Due to sort,16384.2 is backuped after16384.120,so if 16384.120 is a new file, 16384.2 may be copied too.
Luckily,we can solve the problems by initialize the value of bool(prev_file_not_found)