Re: Schema variables - new implementation for Postgres 15
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>, dean.a.rasheed@gmail.com,
er@xs4all.nl, joel@compiler.org, pgsql-hackers@lists.postgresql.org
Date: 2022-11-13T15:01:21Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow underscores in integer and numeric constants.
- faff8f8e47f1 16.0 cited
-
Remove special outfuncs/readfuncs handling of RangeVar.catalogname.
- 3cece34be842 16.0 cited
-
Remove extra space from dumped ALTER DEFAULT PRIVILEGES.
- 2af33369e794 16.0 cited
-
Create FKs properly when attaching table as partition
- b0284bfb1db5 16.0 cited
-
psql: improve tab-complete's handling of variant SQL names.
- 02b8048ba5dc 15.0 cited
Attachments
- v20221113-1-0010-documentation.patch (text/x-patch) patch v20221113-0010
- v20221113-1-0008-regress-tests-for-session-variables.patch (text/x-patch) patch v20221113-0008
- v20221113-1-0007-possibility-to-dump-session-variables-by-pg_dump.patch (text/x-patch) patch v20221113-0007
- v20221113-1-0006-enhancing-psql-for-session-variables.patch (text/x-patch) patch v20221113-0006
- v20221113-1-0009-this-patch-changes-error-message-column-doesn-t-exis.patch (text/x-patch) patch v20221113-0009
- v20221113-1-0005-DISCARD-VARIABLES-command.patch (text/x-patch) patch v20221113-0005
- v20221113-1-0004-support-of-LET-command-in-PLpgSQL.patch (text/x-patch) patch v20221113-0004
- v20221113-1-0003-LET-command.patch (text/x-patch) patch v20221113-0003
- v20221113-1-0002-session-variables.patch (text/x-patch) patch v20221113-0002
- v20221113-1-0001-catalog-support-for-session-variables.patch (text/x-patch) patch v20221113-0001
so 5. 11. 2022 v 17:04 odesílatel Tomas Vondra < tomas.vondra@enterprisedb.com> napsal: > Hi, > > I did a quick initial review of this patch series - attached is a > version with "review" commits for some of the parts. The current patch > seems in pretty good shape, most of what I noticed are minor issues. I > plan to do a more thorough review later. > > A quick overview of the issues: > > 0001 > ---- > > - AtPreEOXact_SessionVariable_on_xact_actions name seems unnecessarily > complicated and redundant, and mismatching nearby functions. Why not > call it AtEOXact_SessionVariable, similar to AtEOXact_LargeObject? > renamed > > - some whitespace / ordering cleanup > > - I'm not sure why find_composite_type_dependencies needs the extra > "else if" branch (instead of just doing "if" as before) > yes, it was not necessary > - NamesFromList and IdentifyVariable seem introduced unnecessarily > early, as they are only used in 0002 and 0003 parts (in the original > patch series). Not sure if the plan is to squash everything into a > single patch, or commit individual patches. > moved to 0002 > > - AFAIK patches don't need to modify typedefs.list. > > > 0002 > ---- > > - some whitespace / ordering cleanup > > - moving setting hasSessionVariables right after similar fields > fixed > > - SessionVariableCreatePostprocess prototype is redundant (2x) > removed > > - I'd probably rename pg_debug_show_used_session_variables to > pg_session_variables (assuming we want to keep this view) > renamed > > > 0003 > ---- > > - I'd rename svariableState to SVariableState, to keep the naming > consistent with other similar/related typedefs. > renamed > - some whitespace / ordering cleanup > > > 0007 > ---- > > - minor wording change > fixed > > > Aside from that, I tried running this under valgrind, and that produces > this report: > > ==250595== Conditional jump or move depends on uninitialised value(s) > ==250595== at 0x731A48: sync_sessionvars_all (session_variable.c:513) > ==250595== by 0x7321A6: prepare_variable_for_reading > (session_variable.c:727) > ==250595== by 0x7320BA: CopySessionVariable (session_variable.c:898) > ==250595== by 0x7BC3BF: standard_ExecutorStart (execMain.c:252) > ==250595== by 0x7BC042: ExecutorStart (execMain.c:146) > ==250595== by 0xA89283: PortalStart (pquery.c:520) > ==250595== by 0xA84E8D: exec_simple_query (postgres.c:1199) > ==250595== by 0xA8425B: PostgresMain (postgres.c:4551) > ==250595== by 0x998B03: BackendRun (postmaster.c:4482) > ==250595== by 0x9980EC: BackendStartup (postmaster.c:4210) > ==250595== by 0x996F0D: ServerLoop (postmaster.c:1804) > ==250595== by 0x9948CA: PostmasterMain (postmaster.c:1476) > ==250595== by 0x8526B6: main (main.c:197) > ==250595== Uninitialised value was created by a heap allocation > ==250595== at 0xCD86F0: MemoryContextAllocExtended (mcxt.c:1138) > ==250595== by 0xC9FA1F: DynaHashAlloc (dynahash.c:292) > ==250595== by 0xC9FEC1: element_alloc (dynahash.c:1715) > ==250595== by 0xCA102A: get_hash_entry (dynahash.c:1324) > ==250595== by 0xCA0879: hash_search_with_hash_value (dynahash.c:1097) > ==250595== by 0xCA0432: hash_search (dynahash.c:958) > ==250595== by 0x731614: SetSessionVariable (session_variable.c:846) > ==250595== by 0x82FEED: svariableReceiveSlot (svariableReceiver.c:138) > ==250595== by 0x7BD277: ExecutePlan (execMain.c:1726) > ==250595== by 0x7BD0C5: standard_ExecutorRun (execMain.c:422) > ==250595== by 0x7BCE63: ExecutorRun (execMain.c:366) > ==250595== by 0x7332F0: ExecuteLetStmt (session_variable.c:1310) > ==250595== by 0xA8CC15: standard_ProcessUtility (utility.c:1076) > ==250595== by 0xA8BC72: ProcessUtility (utility.c:533) > ==250595== by 0xA8B2B9: PortalRunUtility (pquery.c:1161) > ==250595== by 0xA8A454: PortalRunMulti (pquery.c:1318) > ==250595== by 0xA89A16: PortalRun (pquery.c:794) > ==250595== by 0xA84F9E: exec_simple_query (postgres.c:1238) > ==250595== by 0xA8425B: PostgresMain (postgres.c:4551) > ==250595== by 0x998B03: BackendRun (postmaster.c:4482) > ==250595== > > Which I think means this: > > if (filter_lxid && svar->drop_lxid == MyProc->lxid) > continue; > > accesses drop_lxid, which was not initialized in init_session_variable. > fixed Thank you very much for this review. Today's patch should solve all issues reported by Tomas. Regards Pavel > > regards > > -- > Tomas Vondra > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company