From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fix for pg_statio_all_tables |
Date: | 2020-04-21 04:58:20 |
Message-ID: | 25079.1587445100@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-04-21 05:07:09 | Re: It is not documented that pg_promote can exit standby mode |
Previous Message | Michael Paquier | 2020-04-21 04:57:39 | Re: [BUG] non archived WAL removed during production crash recovery |