Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rwDQ1-000BrA-77 for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Apr 2024 03:54:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rwDPy-00AFZA-Kd for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Apr 2024 03:54:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rwDPy-00AFZ2-Ah for pgsql-hackers@lists.postgresql.org; Mon, 15 Apr 2024 03:54:06 +0000 Received: from mail.thelabyrinth.net ([45.56.70.56]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rwDPr-0010AI-AN for pgsql-hackers@postgresql.org; Mon, 15 Apr 2024 03:54:05 +0000 Received: from [10.5.0.2] (unknown [83.136.182.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dsteele) by mail.thelabyrinth.net (Postfix) with ESMTPSA id 3657B54666; Mon, 15 Apr 2024 03:53:55 +0000 (UTC) Message-ID: Date: Mon, 15 Apr 2024 13:53:51 +1000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Pg Hackers , Robert Haas , Tomas Vondra From: David Steele Subject: pg_combinebackup fails on file named INCREMENTAL.* Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hackers, Since incremental backup is using INCREMENTAL as a keyword (rather than storing incremental info in the manifest) it is vulnerable to any file in PGDATA with the pattern INCREMENTAL.*. For example: $ pg_basebackup -c fast -D test/backup/full -F plain $ touch test/data/INCREMENTAL.CONFIG $ /home/dev/test/pg/bin/pg_basebackup -c fast -D test/backup/incr1 -F plain -i /home/dev/test/backup/full/backup_manifest $ /home/dev/test/pg/bin/pg_combinebackup test/backup/full test/backup/incr1 -o test/backup/combine pg_combinebackup: error: could not read file "test/backup/incr1/INCREMENTAL.CONFIG": read only 0 of 4 bytes pg_combinebackup: removing output directory "test/backup/combine" This works anywhere in PGDATA as far as I can see, e.g. $ touch test/data/base/1/INCREMENTAL.1 Or just by dropping a new file into the incremental backup: $ touch test/backup/incr1/INCREMENTAL.x $ /home/dev/test/pg/bin/pg_combinebackup test/backup/full test/backup/incr1 -o test/backup/combine pg_combinebackup: error: could not read file "test/backup/incr1/INCREMENTAL.x": read only 0 of 4 bytes pg_combinebackup: removing output directory "test/backup/combine" We could fix the issue by forbidding this file pattern in PGDATA, i.e. error when it is detected during pg_basebackup, but in my view it would be better (at least eventually) to add incremental info to the manifest. That would also allow us to skip storing zero-length files and incremental stubs (with no changes) as files. Regards, -David