From: | "imai(dot)yoshikazu(at)fujitsu(dot)com" <imai(dot)yoshikazu(at)fujitsu(dot)com> |
---|---|
To: | 'Julien Rouhaud' <rjuju123(at)gmail(dot)com>, legrand legrand <legrand_legrand(at)hotmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Planning counters in pg_stat_statements (using pgss_store) |
Date: | 2020-03-12 05:28:38 |
Message-ID: | OSBPR01MB461601EA9F13C089C3157E6894FD0@OSBPR01MB4616.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Julien,
On Mon, Mar 9, 2020 at 10:32 AM, Julien Rouhaud wrote:
> On Thu, Mar 05, 2020 at 01:26:19PM -0700, legrand legrand wrote:
> > Please consider PG13 shortest path ;o)
> >
> > My one is parse->queryId != UINT64CONST(0) in pgss_planner_hook().
> > It fixes IVM problem (verified),
> > and keep CTAS equal to pgss without planning counters (verified too).
>
> I still disagree that hiding this problem is the right fix, but since no one
> objected here's a v5 with that behavior. Hopefully this will be fixed in v14.
Is there any case that query_text will be NULL when executing pg_plan_query?
If query_text will be NULL, we need to add codes to avoid errors in
pgss_store like as current patch. If query_text will not be NULL, we should
add Assert in pg_plan_query so that other developers can notice that they
would not mistakenly set query_text as NULL even without using pgss_planning
counter.
--
Yoshikazu Imai
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2020-03-12 05:38:11 | Re: Berserk Autovacuum (let's save next Mandrill) |
Previous Message | Thomas Munro | 2020-03-12 05:21:26 | Re: [PATCH] Replica sends an incorrect epoch in its hot standby feedback to the Master |