Fix server crash when EXPLAINing a prepared statement #660
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
58db8d3 to
f1f3604
Compare
JelteF
commented
Mar 11, 2025
| Custom Scan (DuckDBScan) (cost=0.00..0.00 rows=0 width=0) | ||
| Output: duckdb_scan.explain_key, duckdb_scan.explain_value | ||
| Output: duckdb_scan."Count" |
There was a problem hiding this comment.
This is nice additional benefit of this change. The VERBOSE flag now actually lists the columns that the scan returns. For INSERT statements this isn't actually true though, because in postgres those don't return a column at all.
Y--
reviewed
Mar 12, 2025
src/pgduckdb_planner.cpp
Outdated
| Query *copied_query = (Query *)copyObjectImpl(query); | ||
| const char *query_string = pgduckdb_get_querydef(copied_query); | ||
|
|
||
| if (ActivePortal && ActivePortal->commandTag == CMDTAG_EXPLAIN) { | ||
| if (allow_explain && ActivePortal && ActivePortal->commandTag == CMDTAG_EXPLAIN) { |
There was a problem hiding this comment.
Should't the condition be:
Suggested change
| if (allow_explain && ActivePortal && ActivePortal->commandTag == CMDTAG_EXPLAIN) { | |
| if (ActivePortal && ActivePortal->commandTag == CMDTAG_EXPLAIN) { | |
| if (!allow_explain) { | |
| elog(ERROR, ...); | |
| } |
There was a problem hiding this comment.
No it shouldn't, but I totally agree that the argument name suggested that. Instead of renaming it I moved the logic outside of DuckdbPrepare function now.
With a specific query order it was possible that Postgres would cache the plan for the EXPLAINed version of a query instead of the plan for the actual query. This fixes that by only ever adding EXPLAIN to a query when actually executing the query, not also when only planning it. This way the plan that will be cached is always the actual query plan, but at execution time that might be changed in case the query is EXPLAINed.
f1f3604 to
305b227
Compare
JelteF
commented
Mar 12, 2025
| assert "Total Time:" in plan | ||
| # The insert should have been executed exactly once | ||
| assert cur.sql("SELECT * FROM test_table ORDER BY id") == [1, 2, 3, 4, 5] |
There was a problem hiding this comment.
This is currently failing on main...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With a specific query order it was possible that Postgres would cache the plan for the EXPLAINed version of a query instead of the plan for the actual query. This fixes that by only ever adding EXPLAIN to a query when actually executing the query, not also when only planning it. This way the plan that will be cached is always the actual query plan, but at execution time that might be changed in case the query is EXPLAINed.
This also fixes two bugs involving EXPLAIN ANALYZE:
Fixes #410