Robert Haas wrote > On Tue, Apr 2, 2019 at 5:37 AM Christoph Berg <
> myon@ > > wrote: >> Re: Raymond Martin 2019-04-01 < > BN8PR21MB121708579A3782866DF1F745B1550@.outlook > > >> > Thanks again Fabien. I am attaching the patch to this email in the hope >> of getting it approved during the next commit fest. >> >> you sent the patch as UTF-16, could you re-send it as plain ascii? > > One thing that needs some thought here is what happens if the value of > pgss_enabled() changes. For example we don't want a situation where > if the value changes from off to on between one stage of processing > and another, the server crashes. > > I don't know whether that's a risk here or not; it's just something to > think about. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company Hi, here is a simple test where I commented that line in pgss_post_parse_analyze to force return; (as if pgss_enabled() was disabled) but kept pgss_enabled() every where else /* Safety check... */ // if (!pgss || !pgss_hash || !pgss_enabled()) return; This works without crash as you can see here after: postgres=# select pg_stat_statements_reset(); pg_stat_statements_reset -------------------------- (1 row) postgres=# show pg_stat_statements.track; pg_stat_statements.track -------------------------- all (1 row) postgres=# create table a(id int); CREATE TABLE postgres=# select * from a where id=1; id ---- (0 rows) postgres=# select queryid,query,calls from pg_stat_statements; queryid | query | calls ---------------------+-------------------------------+------- 1033669194118974675 | show pg_stat_statements.track | 1 3022461129400094363 | create table a(id int) | 1 (2 rows) regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html