Re: Planning counters in pg_stat_statements (using pgss_store)

From: legrand legrand <legrand_legrand(at)hotmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Planning counters in pg_stat_statements (using pgss_store)
Date: 2020-01-05 18:01:59
Message-ID: 1578247319224-0.post@n3.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Julien Rouhaud wrote
> On Sun, Jan 5, 2020 at 4:11 PM legrand legrand
> &lt;

> legrand_legrand@

> &gt; wrote:
>>
>> Hi Julien,
>>
>> I would like to create a link with
>> https://www.postgresql.org/message-id/

> 1577490124579-0(dot)post(at)(dot)nabble

>>
>> where we met an ASSET FAILURE because query text was not initialized ...
>>
>> The question raised is:
>>
>> - should query text be always provided
>> or
>> - if not how to deal that case (in pgss).
>
> I'd think that since the query text was until now always provided,
> there's no reason why this patch should change that. That being said,
> there has been other concerns raised wrt. temporary tables in the IVM
> patchset, so ISTM that there might be important architectural changes
> upcoming, so having to deal with this case in pgss is not rushed
> (especially since handling that in pgss would be trivial), and can
> help to catch issue with the query text pasing.

IVM revealed that ASSERT,
but IVM works fine with pg_stat_statements.track_planning = off.
There may be others parts of postgresql that would have workede fine as
well.

This means 2 things:
- there is a (litle) risk to meet other assert failures when using planning
counters in pgss,
- we have an easy workarround to fix it (disabling track_planning).

But I would have prefered this new feature to work the same way with or
without track_planning activated ;o(

--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-01-05 18:30:42 Re: pgsql: Add basic TAP tests for psql's tab-completion logic.
Previous Message Tom Lane 2020-01-05 17:33:10 Re: Rethinking opclass member checks and dependency strength