• Tom Lane's avatar
    Handle close() failures more robustly in pg_dump and pg_basebackup. · 6b413b41
    Tom Lane authored
    Coverity complained that applying get_gz_error after a failed gzclose,
    as we did in one place in pg_basebackup, is unsafe.  I think it's
    right: it's entirely likely that the call is touching freed memory.
    Change that to inspect errno, as we do for other gzclose calls.
    
    Also, be careful to initialize errno to zero immediately before any
    gzclose() call where we care about the error status.  (There are
    some calls where we don't, because we already failed at some previous
    step.)  This ensures that we don't get a misleadingly irrelevant
    error code if gzclose() fails in a way that doesn't set errno.
    We could work harder at that, but it looks to me like all such cases
    are basically can't-happen if we're not misusing zlib, so it's
    not worth the extra notational cruft that would be required.
    
    Also, fix several places that simply failed to check for close-time
    errors at all, mostly at some remove from the close or gzclose itself;
    and one place that did check but didn't bother to report the errno.
    
    Back-patch to v12.  These mistakes are older than that, but between
    the frontend logging API changes that happened in v12 and the fact
    that frontend code can't rely on %m before that, the patch would need
    substantial revision to work in older branches.  It doesn't quite
    seem worth the trouble given the lack of related field complaints.
    
    Patch by me; thanks to Michael Paquier for review.
    
    Discussion: https://postgr.es/m/1343113.1636489231@sss.pgh.pa.us
    6b413b41
pg_backup_directory.c 21.9 KB