Re: Schema variables - new implementation for Postgres 15
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Erik Rijkers <er@xs4all.nl>, Dean Rasheed <dean.a.rasheed@gmail.com>, Joel Jacobson <joel@compiler.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-09-03T15:00:51Z
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
Hi, On Fri, Sep 02, 2022 at 07:42:00AM +0200, Pavel Stehule wrote: > > rebased today After some off-list discussion with Pavel, I'm sending some proposal patches (in .txt extension) to apply to the last patchset. To sum up, when a session issues a DROP VARIABLE, the session will receive an sinval notification for its own drop and we don't want to process it immediately as we need to hold the value in case the transaction is rollbacked. The current patch avoided that by forcing a single processing of sinval per transaction, and forcing it before dropping the variable. It works but it seems to me that postponing all but the first VARIABLEOID sinval to the next transaction is a big hammer, and the sooner we can free some memory the better. For an alternative approach the attached patch store the lxid in the SVariable itself when dropping a currently set variable, so we can process all sinval and simply defer to the next transaction the memory cleanup of the variable(s) we know we just dropped. What do you think of that approach? As I was working on some changes I also made a pass on session_variable.c. I tried to improve a bit some comments, and also got rid of the "first_time" variable. The name wasn't really great, and AFAICS it can be replaced by testing whether the memory context has been created yet or not. But once that done I noticed the get_rowtype_value() function. I don't think this function is necessary as the core code already knows how to deal with stored datum when the underlying composite type was modified. I tried to bypass that function and always simply return the stored value and all the tests run fine. Is there really any cases when this extra code is needed? FTR I tried to do a bunch of additional testing using relation as base type for variable, as you can do more with those than plain composite types, but it still always works just fine. However, while doing so I noticed that find_composite_type_dependencies() failed to properly handle dependencies on relation (plain tables, matviews and partitioned tables). I'm also adding 2 additional patches to fix this corner case and add an additional regression test for the plain table case.