Kunshchikov Vladimir wrote:
> Hello Alvaro,
>
> here goes v4 version: removed unused header.
>
> Compilation of this code snippet with -Wall -Wexter -std=c89 doesn't produce
> any warnings.
Great, thanks! I have pushed this to all branches since 9.4. Would you
please give it a look? Please
I haven't seen that but can't guarantee that such case does not exist
28 июля 2017 г. 9:19 PM пользователь "Alvaro Herrera" <
alvhe...@2ndquadrant.com> написал:
> Vladimir Kunschikov wrote:
> > >This "maxlen" business and the fallback error message are
> > >strange. We have roughly equivalent
Vladimir Kunschikov wrote:
> >This "maxlen" business and the fallback error message are
> >strange. We have roughly equivalent code in pg_basebackup.c
> >which has been working since 2011
> >Perhaps you can drop the memchr/fallback tricks and adopt the
> >pg_basebackup coding? Or is there a
>This "maxlen" business and the fallback error message are
>strange. We have roughly equivalent code in pg_basebackup.c
>which has been working since 2011
>Perhaps you can drop the memchr/fallback tricks and adopt the
>pg_basebackup coding? Or is there a specific reason to have
>the memchr
Kunshchikov Vladimir wrote:
> Hello Alvaro,
>
> here goes v4 version: removed unused header.
>
> Compilation of this code snippet with -Wall -Wexter -std=c89 doesn't produce
> any warnings.
Great, thanks.
+const char *
+get_cfp_error(cfp* fp)
+{
+#ifdef HAVE_LIBZ
+ if(fp->compressedfp){
Vladimir
Sent: Thursday, July 27, 2017 10:34:22 AM
To: Alvaro Herrera
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap
Hello, Alvaro,
thanks for the suggestions, attached version #3 with all of your
requirements met.
--
С
s.int/company/structure/Pages/detailsDepartment.aspx?idDepartment=235=17>
From: Alvaro Herrera <alvhe...@2ndquadrant.com>
Sent: Wednesday, July 26, 2017 7:40:20 PM
To: Kunshchikov Vladimir
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [patch] pg_
uly 26, 2017 1:02 AM
To: Kunshchikov Vladimir
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap
Kunshchikov Vladimir wrote:
> Errors should be like this:
> pg_restore: [compress_io] could not read from input file: d3/2811.dat.gz
Kunshchikov Vladimir wrote:
> Hello Alvaro, thanks for the feedback, fixed all of your points.
> Attached new version of patch.
Looks great -- it's a lot smaller than the original even. One final
touch -- see cfread(), where we have an #ifdef where we test for
fp->compressedfp; the "#else"
Kunshchikov Vladimir wrote:
> Errors should be like this:
> pg_restore: [compress_io] could not read from input file: d3/2811.dat.gz:
> invalid distance too far back
>
> Attached small fix for this issue.
After looking at this patch, I don't like it very much. In particular,
I don't like the
Kunshchikov Vladimir wrote:
Hi,
> our testing team has noticed apparently wrong backup/restore error
> messages like this:
>
>
> pg_restore: [compress_io] could not read from input file: success
> pg_dump: [directory archiver] could not write to output file: success
>
>
>
> Such
Hello,
our testing team has noticed apparently wrong backup/restore error messages
like this:
pg_restore: [compress_io] could not read from input file: success
pg_dump: [directory archiver] could not write to output file: success
Such "success" messages are caused by calling strerror()
12 matches
Mail list logo
