Re: Fix for pg_statio_all_tables

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

In response to

Responses

Browse pgsql-hackers by date

  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