From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Julien Rouhaud <rjuju123@gmail.com>, Bruce Momjian <bruce@momjian.us>,
        Robert Haas <robertmhaas@gmail.com>,
        Michael Paquier <michael@paquier.xyz>,
        torikoshia <torikoshia@oss.nttdata.com>,
        Atsushi Torikoshi <atorik@gmail.com>,
        Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>,
        Tomas Vondra <tomas.vondra@2ndquadrant.com>,
        Evgeny Efimkin <efimkin@yandex-team.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Feature improvement: can we add queryId for
 pg_catalog.pg_stat_activity view?
In-reply-to: <20201017155926.GA11995@alvherre.pgsql>
References: <20201017155926.GA11995@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Sat, 17 Oct 2020 12:59:26 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <119779.1602952131.1@sss.pgh.pa.us>
Date: Sat, 17 Oct 2020 12:28:51 -0400
Message-ID: <119780.1602952131@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2020-Oct-17, Julien Rouhaud wrote:
>> On Sat, Oct 17, 2020 at 12:23 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> then there's a potential security issue if the GUC is USERSET level:
>>> a user could hide her queries from pg_stat_statement by turning the
>>> GUC off.  So this line of thought suggests the GUC needs to be at
>>> least SUSET, and maybe higher ... doesn't pg_stat_statement need it
>>> to have the same value cluster-wide?

> I don't think we should consider pg_stat_statement a bulletproof defense
> for security problems.  It is already lossy by design.

Fair point, but if we allow several different values to be set in
different sessions, what ends up happening in pg_stat_statements?

On the other hand, maybe that's just a matter for documentation.
"If the 'same' query is processed with two different queryID settings,
that will generally result in two separate table entries, because
the same ID hash is unlikely to be produced in both cases".  There
is certainly a use-case for wanting to be able to do this, if for
example you'd like different query aggregation behavior for different
applications.

> I do think it'd be preferrable if we allowed it to be disabled at the
> config file level only, not with SET (prevent users from hiding stuff);
> but I think it is useful to allow users to enable it for specific
> queries or for specific sessions only, while globally disabled.

Indeed.  I'm kind of talking myself into the idea that USERSET, or
at most SUSET, is fine, so long as we document what happens when it
has different values in different sessions.

			regards, tom lane