Re: [PATCH] `pg_dump -Fd` doesn't check write return status...

From: Noah Misch <noah(at)leadboat(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Sean Chittenden <sean(at)chittenden(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] `pg_dump -Fd` doesn't check write return status...
Date: 2014-05-06 13:22:20
Message-ID: 20140506132220.GA1317406@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 05, 2014 at 08:29:56PM -0400, Bruce Momjian wrote:
> On Tue, Apr 22, 2014 at 03:19:15PM -0400, Bruce Momjian wrote:
> > As is often the case with pg_dump, the problems you saw are a small part
> > of a larger set of problems in that code --- there is general ignoring of
> > read and write errors.
> >
> > I have developed a comprehensive patch that addresses all the issues I
> > could find. The use of function pointers and the calling of functions
> > directly and through function pointers makes the fix quite complex. I
> > ended up placing checks at the lowest level and removing checks at
> > higher layers where they were sporadically placed.
> >
> > Patch attached. I have tested dump/restore of all four dump output
> > formats with the 9.3 regression database and all tests passed. I
> > believe this patch is too complex to backpatch, and I don't know how it
> > could be fixed more simply.
>
> Patch applied. Thanks for the report.

This broke automatic detection of tar-format dumps:

$ pg_dump -Ft -f tardump
$ pg_restore tardump
pg_restore: [archiver] could not read from input file: Success
$ pg_restore -Ft tardump | wc -c
736

Stack trace:

#0 vwrite_msg (modulename=0x4166c9 "archiver", fmt=0x41aa08 "could not read from input file: %s\n", ap=0x7fffffffde38) at pg_backup_utils.c:85
#1 0x000000000040f820 in exit_horribly (modulename=0x4166c9 "archiver", fmt=0x41aa08 "could not read from input file: %s\n") at parallel.c:190
#2 0x000000000040557d in _discoverArchiveFormat (AH=0x425340) at pg_backup_archiver.c:2040
#3 0x0000000000405756 in _allocAH (FileSpec=0x7fffffffecbb "tardump", fmt=archUnknown, compression=0, mode=archModeRead, setupWorkerPtr=0x4044f0 <setupRestoreWorker>) at pg_backup_archiver.c:2160
#4 0x0000000000405819 in OpenArchive (FileSpec=<optimized out>, fmt=<optimized out>) at pg_backup_archiver.c:148
#5 0x0000000000404331 in main (argc=2, argv=0x7fffffffea28) at pg_restore.c:375

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2014-05-06 13:25:47 Re: sb_alloc: a new memory allocator for PostgreSQL
Previous Message Robert Haas 2014-05-06 13:06:52 Re: Comment patch for index-only scans