Re: Fix for pg_statio_all_tables

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix for pg_statio_all_tables
Date: 2020-04-21 10:19:56
Message-ID: CAPpHfds2EQmfz_2vZXFwabBYLJi1Jew+HyEVgGpK5vE1Y5ZnfA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 21, 2020 at 7:58 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message osumi.takamichi@fujitsu.com 2020-04-21 10:32:14 RE: extension patch of CREATE OR REPLACE TRIGGER
Previous Message Alexander Korotkov 2020-04-21 10:17:40 Re: Fix for pg_statio_all_tables