Re: proposal - queryid can be used as filter for auto_explain
Zsolt Parragi <zsolt.parragi@percona.com>
From: Zsolt Parragi <zsolt.parragi@percona.com>
To: pgsql-hackers@lists.postgresql.org
Date: 2026-06-18T21:01:47Z
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].