pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Alexander Lakhin <exclusion@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Amul Sul <sulamul@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org, Oleg Tkachenko <oatkachenko@gmail.com>
Cc: Stanislav Bashkyrtsev <stanislav.bashkyrtsev@elsci.io>
Subject: Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables
Date: Sun, 25 Jan 2026 14:00:00 +0200
Message-ID: <274e0a1a-d7d2-4bc8-8b56-dd09f285715e@gmail.com> (raw)
In-Reply-To: <CA+TgmoZ_zLO7ROr1KQZ1znqLg3+uL16wc2S01r6UtcwUiHm+_Q@mail.gmail.com>
References: <00FEFC88-EA1D-4271-B38F-EB741733A84A@gmail.com>
	<F687B661-E975-4383-8A94-F9130FE7ACC1@gmail.com>
	<CAAJ_b94y98BWWgf0KMw-E_pqM_y8+RogqHtu5nK0kA1uBE3WWw@mail.gmail.com>
	<CA+TgmoZ7LQ40tLGpHw0U51CReH_8jv0sO0dALGRJp=FT+ZtGFQ@mail.gmail.com>
	<22474984-C4CD-4300-A84E-C1CA58F61CDA@gmail.com>
	<CA+TgmobbxO26OcYcruA=qjSfKeQRzEF_n3_Ljs9ts1MTzCSWxg@mail.gmail.com>
	<A4159D9E-C980-4782-9B91-4B41410AE374@gmail.com>
	<CAAJ_b95v6Kbby_YkBbvAgdujEM7uD7YCTCa62upSZjexsZ8qgw@mail.gmail.com>
	<CA+Tgmoa6aSg-zNDs6F9FtFrjrCozt0_32yQkom9BZsLi-REWAA@mail.gmail.com>
	<08EA8874-0114-4E5C-A794-EB40C971EE7C@gmail.com>
	<CA+Tgmob2j58xsksWMPHfyXBMq4go4qKWyMJWeE6QUugLp6hVXQ@mail.gmail.com>
	<6897DAF7-B699-41BF-A6FB-B818FCFFD585@gmail.com>
	<CA+TgmobgoOHjjHzK1WXnBSR7p2o7VxC1S6cfdEY2cFSKaekfxA@mail.gmail.com>
	<1E2326C0-185A-4D91-867C-18BF94D186DD@gmail.com>
	<CA+TgmoZ_zLO7ROr1KQZ1znqLg3+uL16wc2S01r6UtcwUiHm+_Q@mail.gmail.com>

Hello Robert,

19.01.2026 19:42, Robert Haas wrote:
> On Fri, Jan 16, 2026 at 7:10 AM Oleg Tkachenko <oatkachenko@gmail.com> wrote:
>> As you suggested, I've updated the test so that it produces small files consistently across platforms.
>> On one specific platform (with segment size = 6 blocks), it still exercises the relevant code path.
>> And I've also applied the style changes you mentioned.
> Thanks. I have committed the fix and back-patched to v17. I made some
> style changes to your test, especially rewriting comments, but the
> substance of it is unchanged.

As Windows animal fairywren shows at [1],  the test
011_incremental_backup_truncation_block, added by ecd275718, hit Windows
limitation to the path length:
126/281 postgresql:pg_combinebackup / pg_combinebackup/011_incremental_backup_truncation_block ERROR            96.71s   
(exit status 255 or signal 127 SIGinvalid)

log/011_incremental_backup_truncation_block_primary.log contains:
...
2026-01-20 02:11:14.760 UTC [7480:2] [unknown] LOG:  connection authenticated: user="pgrunner" method=trust 
(C:/tools/xmsys64/home/pgrunner/bf/root/REL_18_STABLE/pgsql.build/testrun/pg_combinebackup/011_incremental_backup_truncation_block/data/t_011_incremental_backup_truncation_block_primary_data/pgdata/pg_hba.conf:117)
...
2026-01-20 02:11:23.506 UTC [1252:3] LOG:  checkpoint starting: immediate force wait
2026-01-20 02:11:23.580 UTC [1252:4] LOG:  checkpoint complete: wrote 5 buffers (3.9%), wrote 1 SLRU buffers; 0 WAL 
file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.001 s, total=0.074 s; sync files=0, longest=0.000 s, 
average=0.000 s; distance=32768 kB, estimate=32768 kB; lsn=0/4000080, redo lsn=0/4000028
2026-01-20 02:11:23.974 UTC [8968:2] ERROR:  could not rename file "pg_wal/summaries/temp.summary" to 
"pg_wal/summaries/00000001000000000100002800000000010CAA50.summary": No such file or directory
         1 file(s) copied.
2026-01-20 02:11:33.645 UTC [7968:14] 011_incremental_backup_truncation_block.pl WARNING:  still waiting for WAL 
summarization through 0/4000028 after 10 seconds
2026-01-20 02:11:33.645 UTC [7968:15] 011_incremental_backup_truncation_block.pl DETAIL:  Summarization has reached 
0/1000000 on disk and 0/10CAA50 in memory.

That is, the target filename for the rename operation is:
C:/tools/xmsys64/home/pgrunner/bf/root/REL_18_STABLE/pgsql.build/testrun/pg_combinebackup/011_incremental_backup_truncation_block/data/t_011_incremental_backup_truncation_block_primary_data/pgdata/pg_wal/summaries/00000001000000000100002800000000010CAA50.summary

I can reproduce this locally with the source tree located at
/c/src/postgresql12345678901234567890123456789012345678901.
Not reproduced with HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled set to 1.

Note that the test passes at the master branch ([2]) because "master" is
shorter than "REL_18_STABLE" by 7 chars.

See also [3].

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fairywren&dt=2026-01-20%2001%3A26%3A02
[2] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=fairywren&dt=2026-01-24%2010%3A03%...
[3] https://www.postgresql.org/message-id/666ac55b-3400-fb2c-2cea-0281bf36a53c%40dunslane.net

Best regards,
Alexander





view thread (19+ messages)  latest in thread

Message-ID: <274e0a1a-d7d2-4bc8-8b56-dd09f285715e@gmail.com>
Permalink:  ../274e0a1a-d7d2-4bc8-8b56-dd09f285715e@gmail.com/
Also on:    postgresql.org/message-id/274e0a1a-d7d2-4bc8-8b56-dd09f285715e@gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: exclusion@gmail.com, robertmhaas@gmail.com, andrew@dunslane.net, sulamul@gmail.com, oatkachenko@gmail.com, stanislav.bashkyrtsev@elsci.io
  Subject: Re: [BUG] [PATCH] pg_basebackup produces wrong incremental files after relation truncation in segmented tables
  In-Reply-To: <274e0a1a-d7d2-4bc8-8b56-dd09f285715e@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox