Re: Fix for pg_statio_all_tables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fix for pg_statio_all_tables
Date
Msg-id 25079.1587445100@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fix for pg_statio_all_tables  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Fix for pg_statio_all_tables  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Do we need to handle orphaned prepared transactions in theserver?
Next
From: Fujii Masao
Date:
Subject: Re: It is not documented that pg_promote can exit standby mode