| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: proposal - queryid can be used as filter for auto_explain |
| Date: | 2026-06-18 21:01:47 |
| Message-ID: | CAN4CZFNn5OE1PW=2PgO_9BReAfT5XxQ+p-uEpPGBduqZjKHcmw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello
+ PGC_SUSET | GUC_LIST_INPUT,
+ 0,
Shouldn't that be PGC_SUSET, GUC_LIST_INPUT?
+ /*
+ * In almost all cases, the queryid is computed due pg_stat_statements.
+ * Without log_queryids computing queryid is not necessary, but it can
+ * be hard to enable or disable queryid in dependecy of log_queryids.
+ * There are two possibilities - force queryid computing, or ignore
+ * queries without computed queryid (computing should be forced by setting
+ * compute_query_id). Boths probably can work, first looks more clean
+ * at this moment.
+ */
+ EnableQueryId();
This comment seems misleading to me. Based on it, I would think that
we always force queryid computing, but EnableQueryId doesn't do
anything with compute_query_id = off, so it seems like the second
choice instead? (also typo: Boths)
+ result = (auto_explain_queryids *) guc_malloc(LOG, allocsize);
+ if (result == NULL)
+ return false;
This leaks rawstring/elemlist, is that intentional?
+ if (*newval == NULL || *newval[0] == '\0')
That should be probably (*newval)[0].
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2026-06-18 21:05:53 | Re: PG20 Minimum Dependency Thread |
| Previous Message | Jacob Champion | 2026-06-18 20:01:47 | PG20 Minimum Dependency Thread |