Re: No error checking when reading from file using zstd in pg_dump
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Evgeniy Gorbanev <gorbanyoves@basealt.ru>,
pgsql-hackers@lists.postgresql.org
Date: 2025-06-16T14:20:07Z
Lists: pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes: >> On 16 Jun 2025, at 15:56, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I've not checked to see what the other users of this API do, but >> if they're all like this then we need to fix that comment. > AFAICT all other callers of this API are throwing an error with pg_fatal, and > so does the function in question for ZStd decompression errors. I think I agree that we need to handle the ferror() case inside the read_func for consistency. But there is another problem, which is that neither of its callers are paying attention to the API: as defined, the read_func can never return anything but "true", which is how Zstd_read behaves. But both the callers in compress_zstd.c seem to think they should test its result to detect EOF. Apparently, our tests do not cover the case of an unexpected EOF. This API is actually quite bizarrely defined, if you ask me. Returning the byte count is optional, but if you don't pay attention to the byte count you cannot know if you got any data. At best, that's bug-encouraging. regards, tom lane
Commits
-
pg_dump: Fix compression API errorhandling
- ec017a305bd4 16.11 landed
- e686010c5b47 19 (unreleased) landed
- 92268b35d04c 17.7 landed
- 8980c724b559 18.0 landed