Re: Fix for pg_statio_all_tables

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fix for pg_statio_all_tables
Дата
Msg-id 25079.1587445100@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fix for pg_statio_all_tables  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Fix for pg_statio_all_tables
Список pgsql-hackers
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?

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Do we need to handle orphaned prepared transactions in theserver?
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: It is not documented that pg_promote can exit standby mode