| 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: | Whole Thread | Raw Message | 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 |