From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: tar-related code in PostgreSQL |
Date: | 2020-04-24 16:27:53 |
Message-ID: | 5009.1587745673@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> We have similar code in many places -- because evidently nobody
> thought it would be a good idea to have all the logic for reading and
> writing tarfiles in a centralized location rather than having many
> copies of it -- and typically it's written to pad the block out to a
> multiple of 512 bytes. But here, the file is 0 bytes long, and then we
> add 511 zero bytes. This results in a tarfile whose length is not a
> multiple of the TAR block size:
Bleah. Whether or not the nearest copy of tar happens to spit up on
that, it's a clear violation of the POSIX standard for tar files.
I'd vote for back-patching your 0001.
I'd lean mildly to holding 0002 until after we branch. It probably
won't break anything, but it probably won't fix anything either.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Juan José Santamaría Flecha | 2020-04-24 17:42:47 | Re: Anybody want to check for Windows timezone updates? |
Previous Message | Jonathan S. Katz | 2020-04-24 16:27:41 | PostgreSQL 13 Beta 1 Release: 2020-05-21 |