Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1laibU-00018b-5N for pgsql-hackers@arkaria.postgresql.org; Sun, 25 Apr 2021 17:31:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1laibS-0005MD-Ts for pgsql-hackers@arkaria.postgresql.org; Sun, 25 Apr 2021 17:31:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1laibS-0005M6-L5 for pgsql-hackers@lists.postgresql.org; Sun, 25 Apr 2021 17:31:30 +0000 Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1laibP-00052j-Tk for pgsql-hackers@lists.postgresql.org; Sun, 25 Apr 2021 17:31:30 +0000 Received: by mail-pj1-x102e.google.com with SMTP id j6-20020a17090adc86b02900cbfe6f2c96so3934018pjv.1 for ; Sun, 25 Apr 2021 10:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=wBFShNuHybIeFPR/PWj5hK9Cahf9m34G5+U+vCs0tfI=; b=f8CH/TDD7m2uEQ0z2pNdm+5djHIVNXabTW2VEUA9ZiA1pJO2lfWmGF2I170HdfVeE4 t1JL6+Z0ckTgx3SWbqqbaVX/+t4Bv+EwpjMxWmlQbRHo8eJ8rB8ar9PGOoVCSyEThnWK +DVVVCT2I8Lso9YFXpTZVwNeUjdk2wpwQV8EKGQGnj5OX9W9YLZI5c8a6MXoFJR/pM3c +p2FiOo6iqSHgLGExVh8oS8Llfd2dZZw6OgS7ddp1QhUSn8fn51fWEDiIH/r2G8HJbqo T6hJwwN/6bOR1BhQXFsVZT2v5hSS/bBC1HQu/6fArvTR8/7HNc2l/dUHYdgl5cVOsAFX qpJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=wBFShNuHybIeFPR/PWj5hK9Cahf9m34G5+U+vCs0tfI=; b=dEHM81uoJ6T/D4SUFLJSQdhUYH0tpX0PRkKNuYxZ0MCy8jPuwzd330UOEH+61NZSnL imwiDcABK/2iDnnVS7clu8WlfTZ6dHz5gayFwqBuDdRHwEfsaRG+DD7TRmMq2oGpAq7o 28bHhoSHyczI+0cfuP4sGwC6icpQVxWMVRxP8EUfGnNoIsnosqOp/sIdUX6waC4mAvAw IhdG/1aryr3Fv3DOkQSM024MwL5CXaCJguMWj2ejqbmusHIwo/eRqkoiWAqlDyjvEAyg GkqFnH9wsF7IUM1C/Bmdb2cV+CrZmtAkjaHayf5NMEt71816aIkAbBrfcbr1BPTmKKd5 zKOA== X-Gm-Message-State: AOAM530goIoXoJme7ZG0tBEAEfvD4J/+laoVj6jdAVW9B/dKaeGdc8Fr RNH5c7dwqaN3sfM8Yv2o+Gw= X-Google-Smtp-Source: ABdhPJznENP6DZc9iaVWMOOW2CDyXhhV9YNycpA58GjQ/p/PqdB+BpuCR0/LGXVUI9o+5kKz34Pz4g== X-Received: by 2002:a17:90a:cd06:: with SMTP id d6mr16524693pju.91.1619371884096; Sun, 25 Apr 2021 10:31:24 -0700 (PDT) Received: from nol (2001-b011-0008-f438-8723-2ad0-f7d3-6c49.dynamic-ip6.hinet.net. [2001:b011:8:f438:8723:2ad0:f7d3:6c49]) by smtp.gmail.com with ESMTPSA id l35sm9009809pgm.10.2021.04.25.10.31.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Apr 2021 10:31:23 -0700 (PDT) Date: Mon, 26 Apr 2021 01:32:06 +0800 From: Julien Rouhaud To: Tom Lane Cc: Bruce Momjian , Magnus Hagander , Fujii Masao , PostgreSQL Developers Subject: Re: compute_query_id and pg_stat_statements Message-ID: <20210425173206.wch7fv3afi5hrxlt@nol> References: <35457b09-36f8-add3-1d07-6034fa585ca8@oss.nttdata.com> <20210424152220.GL7629@momjian.us> <20210424170908.GM7629@momjian.us> <1709439.1619286231@sss.pgh.pa.us> <20210425082251.pokyapaxlzdr7k2t@nol> <1934987.1619365195@sss.pgh.pa.us> <20210425161742.jczixbwvojlsf2wx@nol> <2000204.1619371023@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2000204.1619371023@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Apr 25, 2021 at 01:17:03PM -0400, Tom Lane wrote: > Julien Rouhaud writes: > > On Sun, Apr 25, 2021 at 11:39:55AM -0400, Tom Lane wrote: > >> I agree repeated warnings would be bad news. I was wondering if we could > >> arrange a single warning at the time pg_stat_statements is preloaded into > >> the postmaster. In this way, if you tried to use a configuration file > >> that used to work, you'd hopefully get some notice about why it no longer > >> does what you want. Also, if you are preloading pg_stat_statements, it > >> seems reasonable to assume that you'd like the global value of the flag > >> to be "on", even if there are use-cases for transiently disabling it. > > > What about people who wants to use pg_stat_statements but are not ok with our > > query_id heuristics and use a third-party plugin for that? > > They're still going to want the GUC set to something other than "off", > no? They will want compute_query_id to be off. And they actually will *need* that, as we recommend third-party plugins computing alternative query_id to error out if they see a that a query_id has already been generated, to avoid any problem if compute_query_id is being temporarily toggled. That's what I did in the POC plugin for external query_id at [1]. > In any case it's just a one-time log message, so it's not likely > to be *that* annoying. In that case it should be phrased in a way that makes it clear that pg_stat_statements can work without enabling compute_query_id, something like: "compute_query_id is disabled. This module won't track any activity unless you configured a third-party extension that computes query identifiers" [1] https://github.com/rjuju/pg_queryid/blob/master/pg_queryid.c#L172