pg_dump: could not write to output file: Success
>We don't make any attempt to support filesystems that require retries
Filesystem: VFAT on usb media.Seems like short write was caused not by
filesystem but by gzwrite(), since pg_dump was called with `-F d` switch:
pg_dump -U *** -d **** -v -j 2 -t "alert_counters" -t "aggr_alert_counters"
-t "alerts*" -t "payloads*" -F d -f
"/media/usb0/backup_963871436_2016-01-18_09-16-12"
I think there was EAGAIN error. We are solving this problem now by
suggesting to users rerun of the backup script. I've attached small patch
to the ahwrite() function in my previous posting (it is waiting for the
moderation approval ).
On Tue, Jan 26, 2016 at 5:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
> > On Tue, Jan 26, 2016 at 1:08 AM, Alvaro Herrera
> > <alvherre@2ndquadrant.com> wrote:
> >> Yeah, I noticed this and similar lacks of error checks in pg_dump in
> >> code review, which I didn't get around to patching. Care to submit a
> >> patch?
>
> > Indeed, with a closer look there are things like tarWrite that can
> > return 0 and trigger WRITE_ERROR_EXIT with the same thing. Couldn't we
> > simply check for errno = 0 and generate a more generic error message
> > instead? Or are you willing at replacing all those things with just
> > exit_horribly()?
>
> I do not understand these claims that there isn't an error check there.
> There surely is. But fwrite() didn't set errno.
>
> The real question is why did he get a short write in the first place.
> We don't make any attempt to support filesystems that require retries,
> which seems to be what is going on here. Should we?
>
> regards, tom lane
>