Re: BUG #16179: is it reasonable to callback pgss_post_parse_analyze or pg_hint_plan_post_parse_analyze ???

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: zhq651(at)126(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16179: is it reasonable to callback pgss_post_parse_analyze or pg_hint_plan_post_parse_analyze ???
Date: 2019-12-25 08:48:28
Message-ID: CAOBaU_aNCoKx=y6gRB9Znd3RfNxjpAQLx=O+4j=sYfaA7ydJcA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On Wed, Dec 25, 2019 at 9:32 AM PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference: 16179
> Logged by: DamionZ Zhao
> Email address: zhq651(at)126(dot)com
> PostgreSQL version: 11.5
> Operating system: linux
> Description:
>
> When I only configure GUC as shared_preload_libraries = 'pg_hint_plan,
> pg_stat_statment'
> and have not run sql: 'create extension pg_hint_plan; create extension
> pg_stat_statment',
> I expected that parse_analyze will not run into functions
> :pgss_post_parse_analyze or pg_hint_plan_post_parse_analyze
>
> In fact , it does not . I print runtime call stack.
> -----------------------------------------------------
> statment 1: select
> #0 pgss_post_parse_analyze (pstate=0x2a45818, query=0x2a45928) at
> pg_stat_statements.c:812
> #1 0x00007fbe60506734 in pg_hint_plan_post_parse_analyze (pstate=0x2a45818,
> query=0x2a45928) at pg_hint_plan.c:2767
> #2 0x000000000058fbe5 in parse_analyze (parseTree=0x2a45798,
> sourceText=0x2a44a90 "select * from abcd;", paramTypes=0x0, numParams=0,
> queryEnv=0x0) at analyze.c:124
> [...]
>
> It will degrade performance and may cause the wrong result if it contains
> modify operation.

This is expected. The hooks are called as soon as the libraries are
loaded, so configuring shared_preload_libraries (and restarting
postgres) will activate the extensions. What you should do instead is
disable pg_stat_statements (or other extensions if they have such
possibility) if you want to be able to use it only when required,
without the need to restart postgres. The CREATE EXTENSION part is
only necessary to access the counters stored in shared memory.

Regarding the performance overhead, it's true that the queryid
generation will still happen even if you disable pg_stat_statements.
However, note that this will be fixed with pg13, see
https://www.postgresql.org/message-id/BN8PR21MB1217B003C4F79DE230AA36B9B1580%40BN8PR21MB1217.namprd21.prod.outlook.com
for more details.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Загороднев Роман Евгеньевич 2019-12-25 13:10:42 pg_upgrade
Previous Message PG Bug reporting form 2019-12-25 08:31:24 BUG #16179: is it reasonable to callback pgss_post_parse_analyze or pg_hint_plan_post_parse_analyze ???