Error in pg_restore (could not close data file: Success)
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t43116psql -h localhost -U postgresBuilt from patchset v3 (message #3), July 27, 2026 at 06:18 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t43116_3 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t43116_3 && git checkout t43116_3Patchset v3 (message #3) is on t43116_3
Hello,
After restoring 'directory' backup with pg_restore (PostgreSQL 10.6) I've
got a message:
pg_restore: [directory archiver] could not close data file: Success
pg_restore: [parallel archiver] a worker process died unexpectedly
In this thread:
/messages/by-id/CAFcNs+os5ExGvXMBrBBzzuJJamoHt5-zdJdxX39nkVG0KUxwsw@mail.gmail.com
there is only one answer. I'm interesting, is it normal behaivor of
pg_restore and backup restored normaly or not ?
Regards, Andrii
At Tue, 20 Oct 2020 13:48:25 +0300, Andrii Tkach <and7ua@gmail.com> wrote in
Hello,
After restoring 'directory' backup with pg_restore (PostgreSQL 10.6) I've
got a message:
pg_restore: [directory archiver] could not close data file: Success
pg_restore: [parallel archiver] a worker process died unexpectedly
In this thread:
/messages/by-id/CAFcNs+os5ExGvXMBrBBzzuJJamoHt5-zdJdxX39nkVG0KUxwsw@mail.gmail.com
there is only one answer. I'm interesting, is it normal behaivor of
pg_restore and backup restored normaly or not ?
That would be a broken compressed file, maybe caused by disk full.
This reminded me of a thread. The issue above seems to be the same
with this:
/messages/by-id/20200416.181945.759179589924840062.horikyota.ntt@gmail.com
Me> Hmm. Sounds reasonable. I'm going to do that. Thanks!
But somehow that haven't happened, I'll come up with a new version.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Wed, 21 Oct 2020 13:45:15 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in
/messages/by-id/20200416.181945.759179589924840062.horikyota.ntt@gmail.com
Me> Hmm. Sounds reasonable. I'm going to do that. Thanks!
But somehow that haven't happened, I'll come up with a new version.
pg_restore shows the following error instead of "Success" for broken
compressed file.
pg_restore: error: could not close data file "d/3149.dat": zlib error: error reading or writing compressed file
0001:
cfclose() calls fatal() instead of returning the result to the callers
on error, which isobviously okay for all existing callers that are
handling errors from the function. Other callers ignored the returned
value but we should fatal() on error of the function.
At least for me, gzerror doesn't return a message (specifically,
returns NULL) after gzclose failure so currently cfclose shows its own
messages for erros of gzclose(). Am I missing something?
0002:
cfread has the same code with get_cfp_error() and cfgetc uses
sterror() after gzgetc(). It would be suitable for a separate patch,
but 0002 fixes those bugs. I changed _EndBlob() to show the cause of
an error.
Did not do in this patch:
We could do further small refactoring to remove temporary variables in
pg_backup_directory.c for _StartData(), InitArchiveFmt_Directory,
_LoadBlobs(), _StartBlobs() and _CloseArchive(), but I left them as is
for the ease of back-patching.
Now that we have the file name in the context variable so we could
show the file name in all error messages, but that change was large
and there's a part where that change is a bit more complex so I didn't
do that.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
Maybe it would be better to commit this patches to mainstream, but I don't
realy know.
ср, 21 окт. 2020 г. в 09:20, Kyotaro Horiguchi <horikyota.ntt@gmail.com>:
Show quoted text
At Wed, 21 Oct 2020 13:45:15 +0900 (JST), Kyotaro Horiguchi <
horikyota.ntt@gmail.com> wrote in/messages/by-id/20200416.181945.759179589924840062.horikyota.ntt@gmail.com
Me> Hmm. Sounds reasonable. I'm going to do that. Thanks!
But somehow that haven't happened, I'll come up with a new version.
pg_restore shows the following error instead of "Success" for broken
compressed file.pg_restore: error: could not close data file "d/3149.dat": zlib error:
error reading or writing compressed file0001:
cfclose() calls fatal() instead of returning the result to the callers
on error, which isobviously okay for all existing callers that are
handling errors from the function. Other callers ignored the returned
value but we should fatal() on error of the function.At least for me, gzerror doesn't return a message (specifically,
returns NULL) after gzclose failure so currently cfclose shows its own
messages for erros of gzclose(). Am I missing something?0002:
cfread has the same code with get_cfp_error() and cfgetc uses
sterror() after gzgetc(). It would be suitable for a separate patch,
but 0002 fixes those bugs. I changed _EndBlob() to show the cause of
an error.Did not do in this patch:
We could do further small refactoring to remove temporary variables in
pg_backup_directory.c for _StartData(), InitArchiveFmt_Directory,
_LoadBlobs(), _StartBlobs() and _CloseArchive(), but I left them as is
for the ease of back-patching.Now that we have the file name in the context variable so we could
show the file name in all error messages, but that change was large
and there's a part where that change is a bit more complex so I didn't
do that.regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center