Re: Fix for pg_statio_all_tables
От | Alexander Korotkov |
---|---|
Тема | Re: Fix for pg_statio_all_tables |
Дата | |
Msg-id | CAPpHfds2EQmfz_2vZXFwabBYLJi1Jew+HyEVgGpK5vE1Y5ZnfA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fix for pg_statio_all_tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Fix for pg_statio_all_tables
|
Список | pgsql-hackers |
On Tue, Apr 21, 2020 at 7:58 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael@paquier.xyz> writes: > > On Tue, Apr 21, 2020 at 02:44:45AM +0300, Alexander Korotkov wrote: > >> As a bugfix, I think this should be backpatched. But this patch > >> requires catalog change. Were similar cases there before? If so, > >> how did we resolve them? > > > A backpatch can happen in such cases, see for example b6e39ca9. In > > this case, the resolution was done with a backpatch to > > system_views.sql and the release notes include an additional note > > saying that the fix applies itself only on already-initialized > > clusters. For other clusters, it was necessary to apply a SQL query, > > given also in the release notes, to fix the issue (just grep for > > CVE-2017-7547 in release-9.6.sgml on the REL9_6_STABLE branch). > > Yeah, but that was for a security hole. I am doubtful that the > severity of this problem is bad enough to justify jumping through > similar hoops. Even if we fixed it and documented it, how many > users would bother to apply the manual correction? Sure, only most conscious users will do the manual correction. But if there are only two option: backpatch it this way or don't backpatch at all, then I would choose the first one. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
В списке pgsql-hackers по дате отправления: