Re: proposal - queryid can be used as filter for auto_explain - Mailing list pgsql-hackers

From Zsolt Parragi
Subject Re: proposal - queryid can be used as filter for auto_explain
Date
Msg-id CAN4CZFNn5OE1PW=2PgO_9BReAfT5XxQ+p-uEpPGBduqZjKHcmw@mail.gmail.com
Whole thread
Responses Re: proposal - queryid can be used as filter for auto_explain
List 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].



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: PG20 Minimum Dependency Thread
Next
From: Daniel Gustafsson
Date:
Subject: Re: PG20 Minimum Dependency Thread