Merge branch 'postgres:master' into main

pmp-p · web-flow · commit d6a93461eab9 · 2024-04-16T09:48:14.000+02:00
diff --git a/doc/src/sgml/custom-rmgr.sgml b/doc/src/sgml/custom-rmgr.sgml
@@ -1,10 +1,10 @@
 <!-- doc/src/sgml/custom-rmgr.sgml -->
 
-<chapter id="custom-rmgr">
+<sect1 id="custom-rmgr">
  <title>Custom WAL Resource Managers</title>
 
  <para>
-  This chapter explains the interface between the core
+  This section explains the interface between the core
   <productname>PostgreSQL</productname> system and custom WAL resource
   managers, which enable extensions to integrate directly with the <link
   linkend="wal"><acronym>WAL</acronym></link>.
@@ -13,10 +13,7 @@
   An extension, especially a <link linkend="tableam">Table Access
   Method</link> or <link linkend="indexam">Index Access Method</link>, may
   need to use WAL for recovery, replication, and/or <link
-  linkend="logicaldecoding">Logical Decoding</link>. Custom resource managers
-  are a more flexible alternative to <link linkend="generic-wal">Generic
-  WAL</link> (which does not support logical decoding), but more complex for
-  an extension to implement.
+  linkend="logicaldecoding">Logical Decoding</link>.
  </para>
  <para>
   To create a new custom WAL resource manager, first define an
@@ -102,4 +99,4 @@ extern void RegisterCustomRmgr(RmgrId rmid, const RmgrData *rmgr);
     the custom WAL records, which may prevent the server from starting.
    </para>
  </note>
-</chapter>
+</sect1>
diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
@@ -107,6 +107,7 @@
 <!ENTITY storage    SYSTEM "storage.sgml">
 <!ENTITY transaction     SYSTEM "xact.sgml">
 <!ENTITY tablesample-method SYSTEM "tablesample-method.sgml">
+<!ENTITY wal-for-extensions SYSTEM "wal-for-extensions.sgml">
 <!ENTITY generic-wal SYSTEM "generic-wal.sgml">
 <!ENTITY custom-rmgr SYSTEM "custom-rmgr.sgml">
 <!ENTITY backup-manifest SYSTEM "backup-manifest.sgml">
diff --git a/doc/src/sgml/generic-wal.sgml b/doc/src/sgml/generic-wal.sgml
@@ -1,20 +1,12 @@
 <!-- doc/src/sgml/generic-wal.sgml -->
 
-<chapter id="generic-wal">
+<sect1 id="generic-wal">
  <title>Generic WAL Records</title>
 
   <para>
    Although all built-in WAL-logged modules have their own types of WAL
    records, there is also a generic WAL record type, which describes changes
-   to pages in a generic way. This is useful for extensions that provide
-   custom access methods.
-  </para>
-
-  <para>
-   In comparison with <link linkend="custom-rmgr">Custom WAL Resource
-   Managers</link>, Generic WAL is simpler for an extension to implement and
-   does not require the extension library to be loaded in order to apply the
-   records.
+   to pages in a generic way.
   </para>
 
   <note>
@@ -171,4 +163,4 @@
     </listitem>
    </itemizedlist>
   </para>
-</chapter>
+</sect1>
diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
@@ -256,8 +256,7 @@ break is not needed in a wider output rendering.
   &geqo;
   &tableam;
   &indexam;
-  &generic-wal;
-  &custom-rmgr;
+  &wal-for-extensions;
   &indextypes;
   &storage;
   &transaction;
diff --git a/doc/src/sgml/ref/set_role.sgml b/doc/src/sgml/ref/set_role.sgml
@@ -37,7 +37,10 @@ RESET ROLE
    written as either an identifier or a string literal.
    After <command>SET ROLE</command>, permissions checking for SQL commands
    is carried out as though the named role were the one that had logged
-   in originally.
+   in originally.  Note that <command>SET ROLE</command> and
+   <command>SET SESSION AUTHORIZATION</command> are exceptions; permissions
+   checks for those continue to use the current session user and the initial
+   session user (the <firstterm>authenticated user</firstterm>), respectively.
   </para>
 
   <para>
@@ -88,11 +91,6 @@ RESET ROLE
    exercised either with or without <literal>SET ROLE</literal>.
   </para>
 
-  <para>
-   Note that when a superuser chooses to <command>SET ROLE</command> to a
-   non-superuser role, they lose their superuser privileges.
-  </para>
-
   <para>
    <command>SET ROLE</command> has effects comparable to
    <link linkend="sql-set-session-authorization"><command>SET SESSION AUTHORIZATION</command></link>, but the privilege
diff --git a/doc/src/sgml/wal-for-extensions.sgml b/doc/src/sgml/wal-for-extensions.sgml
@@ -0,0 +1,32 @@
+<!-- doc/src/sgml/wal-for-extensions.sgml -->
+
+<chapter id="wal-for-extensions">
+ <title>Write Ahead Logging for Extensions</title>
+
+  <para>
+   Certain extensions, principally extensions that implement custom access
+   methods, may need to perform write-ahead logging in order to ensure
+   crash-safety. <productname>PostgreSQL</productname> provides two ways
+   for extensions to achieve this goal.
+  </para>
+
+  <para>
+   First, extensions can choose to use <link linkend="generic-wal">generic
+   WAL</link>, a special type of WAL record which describes changes to pages
+   in a generic way. This method is simple to implement and does not require
+   that an extension library be loaded in order to apply the records. However,
+   generic WAL records will be ignored when performing logical decoding.
+  </para>
+
+  <para>
+   Second, extensions can choose to use a <link linkend="custom-rmgr">custom
+   resource manager</link>. This method is more flexible, supports logical
+   decoding, and can sometimes generate much smaller write-ahead log records
+   than would be possible with generic WAL. However, it is more complex for an
+   extension to implement.
+  </para>
+
+&generic-wal;
+&custom-rmgr;
+
+</chapter>
diff --git a/src/backend/catalog/dependency.c b/src/backend/catalog/dependency.c
@@ -2337,7 +2337,11 @@ process_function_rte_ref(RangeTblEntry *rte, AttrNumber attnum,
 		{
 			TupleDesc	tupdesc;
 
-			tupdesc = get_expr_result_tupdesc(rtfunc->funcexpr, true);
+			/* If it has a coldeflist, it certainly returns RECORD */
+			if (rtfunc->funccolnames != NIL)
+				tupdesc = NULL; /* no need to work hard */
+			else
+				tupdesc = get_expr_result_tupdesc(rtfunc->funcexpr, true);
 			if (tupdesc && tupdesc->tdtypeid != RECORDOID)
 			{
 				/*
diff --git a/src/backend/optimizer/prep/prepjointree.c b/src/backend/optimizer/prep/prepjointree.c
@@ -1854,6 +1854,10 @@ pull_up_constant_function(PlannerInfo *root, Node *jtnode,
 	if (rtf->funccolcount != 1)
 		return jtnode;			/* definitely composite */
 
+	/* If it has a coldeflist, it certainly returns RECORD */
+	if (rtf->funccolnames != NIL)
+		return jtnode;			/* must be a one-column RECORD type */
+
 	functypclass = get_expr_result_type(rtf->funcexpr,
 										&funcrettype,
 										&tupdesc);
diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c
@@ -4431,12 +4431,11 @@ evaluate_function(Oid funcid, Oid result_type, int32 result_typmod,
 	 * Can't simplify if it returns RECORD.  The immediate problem is that it
 	 * will be needing an expected tupdesc which we can't supply here.
 	 *
-	 * In the case where it has OUT parameters, it could get by without an
-	 * expected tupdesc, but we still have issues: get_expr_result_type()
-	 * doesn't know how to extract type info from a RECORD constant, and in
-	 * the case of a NULL function result there doesn't seem to be any clean
-	 * way to fix that.  In view of the likelihood of there being still other
-	 * gotchas, seems best to leave the function call unreduced.
+	 * In the case where it has OUT parameters, we could build an expected
+	 * tupdesc from those, but there may be other gotchas lurking.  In
+	 * particular, if the function were to return NULL, we would produce a
+	 * null constant with no remaining indication of which concrete record
+	 * type it is.  For now, seems best to leave the function call unreduced.
 	 */
 	if (funcform->prorettype == RECORDOID)
 		return NULL;
diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.c
@@ -2738,12 +2738,17 @@ expandRTE(RangeTblEntry *rte, int rtindex, int sublevels_up,
 				{
 					RangeTblFunction *rtfunc = (RangeTblFunction *) lfirst(lc);
 					TypeFuncClass functypclass;
-					Oid			funcrettype;
-					TupleDesc	tupdesc;
+					Oid			funcrettype = InvalidOid;
+					TupleDesc	tupdesc = NULL;
+
+					/* If it has a coldeflist, it returns RECORD */
+					if (rtfunc->funccolnames != NIL)
+						functypclass = TYPEFUNC_RECORD;
+					else
+						functypclass = get_expr_result_type(rtfunc->funcexpr,
+															&funcrettype,
+															&tupdesc);
 
-					functypclass = get_expr_result_type(rtfunc->funcexpr,
-														&funcrettype,
-														&tupdesc);
 					if (functypclass == TYPEFUNC_COMPOSITE ||
 						functypclass == TYPEFUNC_COMPOSITE_DOMAIN)
 					{
@@ -3369,6 +3374,10 @@ get_rte_attribute_is_dropped(RangeTblEntry *rte, AttrNumber attnum)
 					{
 						TupleDesc	tupdesc;
 
+						/* If it has a coldeflist, it returns RECORD */
+						if (rtfunc->funccolnames != NIL)
+							return false;	/* can't have any dropped columns */
+
 						tupdesc = get_expr_result_tupdesc(rtfunc->funcexpr,
 														  true);
 						if (tupdesc)
diff --git a/src/backend/utils/fmgr/funcapi.c b/src/backend/utils/fmgr/funcapi.c
@@ -287,6 +287,13 @@ get_call_result_type(FunctionCallInfo fcinfo,
 /*
  * get_expr_result_type
  *		As above, but work from a calling expression node tree
+ *
+ * Beware of using this on the funcexpr of a RTE that has a coldeflist.
+ * The correct conclusion in such cases is always that the function returns
+ * RECORD with the columns defined by the coldeflist fields (funccolnames etc).
+ * If it does not, it's the executor's responsibility to catch the discrepancy
+ * at runtime; but code processing the query in advance of that point might
+ * come to inconsistent conclusions if it checks the actual expression.
  */
 TypeFuncClass
 get_expr_result_type(Node *expr,
@@ -537,7 +544,8 @@ internal_get_result_type(Oid funcid,
  * if noError is true, else throws error.
  *
  * This is a simpler version of get_expr_result_type() for use when the caller
- * is only interested in determinate rowtype results.
+ * is only interested in determinate rowtype results.  As with that function,
+ * beware of using this on the funcexpr of a RTE that has a coldeflist.
  */
 TupleDesc
 get_expr_result_tupdesc(Node *expr, bool noError)
diff --git a/src/include/postmaster/postmaster.h b/src/include/postmaster/postmaster.h
@@ -52,7 +52,7 @@ extern PGDLLIMPORT int postmaster_alive_fds[2];
 
 extern PGDLLIMPORT const char *progname;
 
-extern bool LoadedSSL;
+extern PGDLLIMPORT bool LoadedSSL;
 
 extern void PostmasterMain(int argc, char *argv[]) pg_attribute_noreturn();
 extern void ClosePostmasterPorts(bool am_syslogger);
@@ -74,7 +74,7 @@ extern void pgwin32_register_deadchild_callback(HANDLE procHandle, DWORD procId)
 #endif
 
 /* defined in globals.c */
-extern struct ClientSocket *MyClientSocket;
+extern PGDLLIMPORT struct ClientSocket *MyClientSocket;
 
 /* prototypes for functions in launch_backend.c */
 extern pid_t postmaster_child_launch(BackendType child_type, char *startup_data, size_t startup_data_len, struct ClientSocket *sock);
diff --git a/src/test/regress/expected/rangefuncs.out b/src/test/regress/expected/rangefuncs.out
@@ -2498,3 +2498,6 @@ with a(b) as (values (row(1,2,3)))
 select * from a, coalesce(b) as c(d int, e int, f float);  -- fail
 ERROR:  function return row and query-specified return row do not match
 DETAIL:  Returned type integer at ordinal position 3, but query expects double precision.
+select * from int8_tbl, coalesce(row(1)) as (a int, b int);  -- fail
+ERROR:  function return row and query-specified return row do not match
+DETAIL:  Returned row contains 1 attribute, but query expects 2.
diff --git a/src/test/regress/expected/sysviews.out b/src/test/regress/expected/sysviews.out
@@ -28,6 +28,29 @@ select name, ident, parent, level, total_bytes >= free_bytes
  TopMemoryContext |       |        |     0 | t
 (1 row)
 
+-- We can exercise some MemoryContext type stats functions.  Most of the
+-- column values are too platform-dependant to display.
+-- Ensure stats from the bump allocator look sane.  Bump isn't a commonly
+-- used context, but it is used in tuplesort.c, so open a cursor to keep
+-- the tuplesort alive long enough for us to query the context stats.
+begin;
+declare cur cursor for select left(a,10), b
+  from (values(repeat('a', 512 * 1024),1),(repeat('b', 512),2)) v(a,b)
+  order by v.a desc;
+fetch 1 from cur;
+    left    | b 
+------------+---
+ bbbbbbbbbb | 2
+(1 row)
+
+select name, parent, total_bytes > 0, total_nblocks, free_bytes > 0, free_chunks
+from pg_backend_memory_contexts where name = 'Caller tuples';
+     name      |     parent     | ?column? | total_nblocks | ?column? | free_chunks 
+---------------+----------------+----------+---------------+----------+-------------
+ Caller tuples | TupleSort sort | t        |             3 | t        |           0
+(1 row)
+
+rollback;
 -- At introduction, pg_config had 23 entries; it may grow
 select count(*) > 20 as ok from pg_config;
  ok 
diff --git a/src/test/regress/expected/tuplesort.out b/src/test/regress/expected/tuplesort.out
@@ -343,6 +343,19 @@ ORDER BY ctid DESC LIMIT 5;
 (5 rows)
 
 ROLLBACK;
+----
+-- test sorting of large datums VALUES
+----
+-- Ensure the order is correct and values look intact
+SELECT LEFT(a,10),b FROM
+    (VALUES(REPEAT('a', 512 * 1024),1),(REPEAT('b', 512 * 1024),2)) v(a,b)
+ORDER BY v.a DESC;
+    left    | b 
+------------+---
+ bbbbbbbbbb | 2
+ aaaaaaaaaa | 1
+(2 rows)
+
 ----
 -- test forward and backward scans for in-memory and disk based tuplesort
 ----
diff --git a/src/test/regress/sql/rangefuncs.sql b/src/test/regress/sql/rangefuncs.sql
@@ -824,3 +824,4 @@ with a(b) as (values (row(1,2,3)))
 select * from a, coalesce(b) as c(d int, e int, f int, g int);  -- fail
 with a(b) as (values (row(1,2,3)))
 select * from a, coalesce(b) as c(d int, e int, f float);  -- fail
+select * from int8_tbl, coalesce(row(1)) as (a int, b int);  -- fail
diff --git a/src/test/regress/sql/sysviews.sql b/src/test/regress/sql/sysviews.sql
@@ -17,6 +17,21 @@ select count(*) >= 0 as ok from pg_available_extensions;
 select name, ident, parent, level, total_bytes >= free_bytes
   from pg_backend_memory_contexts where level = 0;
 
+-- We can exercise some MemoryContext type stats functions.  Most of the
+-- column values are too platform-dependant to display.
+
+-- Ensure stats from the bump allocator look sane.  Bump isn't a commonly
+-- used context, but it is used in tuplesort.c, so open a cursor to keep
+-- the tuplesort alive long enough for us to query the context stats.
+begin;
+declare cur cursor for select left(a,10), b
+  from (values(repeat('a', 512 * 1024),1),(repeat('b', 512),2)) v(a,b)
+  order by v.a desc;
+fetch 1 from cur;
+select name, parent, total_bytes > 0, total_nblocks, free_bytes > 0, free_chunks
+from pg_backend_memory_contexts where name = 'Caller tuples';
+rollback;
+
 -- At introduction, pg_config had 23 entries; it may grow
 select count(*) > 20 as ok from pg_config;
 
diff --git a/src/test/regress/sql/tuplesort.sql b/src/test/regress/sql/tuplesort.sql
@@ -146,6 +146,15 @@ FROM abbrev_abort_uuids
 ORDER BY ctid DESC LIMIT 5;
 ROLLBACK;
 
+----
+-- test sorting of large datums VALUES
+----
+
+-- Ensure the order is correct and values look intact
+SELECT LEFT(a,10),b FROM
+    (VALUES(REPEAT('a', 512 * 1024),1),(REPEAT('b', 512 * 1024),2)) v(a,b)
+ORDER BY v.a DESC;
+
 ----
 -- test forward and backward scans for in-memory and disk based tuplesort
 ----

Original file line number	Diff line number	Diff line change
`@@ -2337,7 +2337,11 @@ process_function_rte_ref(RangeTblEntry *rte, AttrNumber attnum,`
`2337`	`2337`	`{`
`2338`	`2338`	`TupleDesc tupdesc;`
`2339`	`2339`
`2340`		`- tupdesc = get_expr_result_tupdesc(rtfunc->funcexpr, true);`
	`2340`	`+ /* If it has a coldeflist, it certainly returns RECORD */`
	`2341`	`+ if (rtfunc->funccolnames != NIL)`
	`2342`	`+ tupdesc = NULL; /* no need to work hard */`
	`2343`	`+ else`
	`2344`	`+ tupdesc = get_expr_result_tupdesc(rtfunc->funcexpr, true);`
`2341`	`2345`	`if (tupdesc && tupdesc->tdtypeid != RECORDOID)`
`2342`	`2346`	`{`
`2343`	`2347`	`/*`