Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror()mishap
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror()mishap |
Дата | |
Msg-id | 20170728181913.owfihtuye2ki6agv@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap (Vladimir Kunschikov <kunschikov@gmail.com>) |
Ответы |
Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap
|
Список | pgsql-hackers |
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 specific reason to have > >the memchr check? > > Ofcourse that tricks can be dropped, function will be much prettier. > 'Tricks' were made to pass some strict internal tests. Well, if there are cases which cause zlib to return a message that causes a crash when printing it or some other problem, then let's use your version both in this new code and in pg_basebackup. Do these cases really exist? > Initially I used exactly that function from pg_basebackup.c: > https://github.com/kunschikov/postgres/commit/15e9fda6df51cf17c0b0a4f201ee0f93cf258de9#diff-98e3f8ce5d6e87950dd66e4c8bdedb21R713 > It was rewritten for the sake of somewhat exaggerated security. > Version #5 in attachment. I'd rather have all the security we can get, so before dropping those protections, let's make sure they are useless. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: