Remove nonfunctional tar file trailer size check.

The ASTREAMER_ARCHIVE_TRAILER case in astreamer_tar_parser_content()
intended to reject tar files whose trailer exceeded 2 blocks.  However,
the check compared 'len' after astreamer_buffer_bytes() had already
consumed all the data and set len to 0, so the pg_fatal() could never
fire.

Moreover, per the POSIX specification for the ustar format, the last
physical block of a tar archive is always full-sized, and "logical
records after the two zero logical records may contain undefined data."
GNU tar, for example, zero-pads its output to a 10kB boundary by
default.  So rejecting extra data after the two zero blocks would be
wrong even if the check worked.  (But if the check had worked, it
would have alerted us to the bug just fixed in 9aa1fcc54.)

Remove the dead check and update the comment to explain why trailing
data is expected and harmless.

Per report from Tom Lane.

Author: Andrew Dunstan <andrew@dunslane.net>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/2178517.1774064942@sss.pgh.pa.us
This commit is contained in:
Tom Lane 2026-03-22 18:13:41 -04:00
parent 9aa1fcc547
commit 5868372bbf

View file

@ -236,12 +236,16 @@ astreamer_tar_parser_content(astreamer *streamer, astreamer_member *member,
/*
* We've seen an end-of-archive indicator, so anything more is
* buffered and sent as part of the archive trailer. But we
* don't expect more than 2 blocks.
* buffered and sent as part of the archive trailer.
*
* Per POSIX, the last physical block of a tar archive is
* always full-sized, so there may be undefined data after the
* two zero blocks that mark end-of-archive. GNU tar, for
* example, zero-pads to a 10kB boundary by default. We just
* buffer whatever we receive and pass it along at finalize
* time.
*/
astreamer_buffer_bytes(streamer, &data, &len, len);
if (len > 2 * TAR_BLOCK_SIZE)
pg_fatal("tar file trailer exceeds 2 blocks");
return;
default: