Compare commits

...

6 Commits

Author SHA1 Message Date
Michael Paquier
40d5e5981c Fix 003_check_guc.pl when loading modules with custom GUCs
The test missed that custom GUCs need to be ignored from the list of
parameters that can exist in postgresql.conf.sample.  This caused the
test to fail on a server where such a module is loaded, when using
EXTRA_INSTALL and TEMP_CONFIG, for instance.

Author: Anton A. Melnikov
Discussion: https://postgr.es/m/fc5509ce-5144-4dac-8d13-21793da44fc5@postgrespro.ru
Backpatch-through: 15
2023-11-02 12:38:05 +09:00
David Rowley
cac169d686 Increase DEFAULT_FDW_TUPLE_COST from 0.01 to 0.2
0.01 was unrealistically low as it's the same as the default
cpu_tuple_cost and 10x cheaper than the default parallel_tuple_cost.
It's hard to imagine a situation where fetching a tuple from a foreign
server would be cheaper than fetching one from a parallel worker.

After some experimentation on a loopback server, somewhere between 0.15
and 0.3 seems more realistic.  Here we split the difference and set it
to 0.2.

This will cause operations that reduce the number of tuples (e.g.
aggregation) to be more likely to take place on the foreign server.

Adjusting this causes some plan changes in the postgres_fdw regression
tests.  This is because penalizing each Path with the additional tuple
costs causes some dilution of the costs of the other operations being
charged for and results in various paths appearing to be closer to the
same costs such that add_path's STD_FUZZ_FACTOR is more likely to see two
paths as costing (fuzzily) the same.  This isn't ideal, but it shouldn't
be reason enough to use artificially low costs.

Discussion: https://postgr.es/m/CAApHDvopVjjfh5c1Ed2HRvDdfom2dEpMwwiu5-f1AnmYprJngA@mail.gmail.com
2023-11-02 14:30:15 +13:00
Michael Paquier
4210b55f59 doc: Replace reference to ERRCODE_RAISE_EXCEPTION by "raise_exception"
This part of the documentation refers to exceptions as handled by
PL/pgSQL, and using the internal error code is confusing.

Per thinko in 66bde49d96a9.

Reported-by: Euler Taveira, Bruce Momjian
Discussion: https://postgr.es/m/ZUEUnLevXyW7DlCs@momjian.us
Backpatch-through: 11
2023-11-02 07:33:02 +09:00
Bruce Momjian
783e816666 doc: add reference to wire protocol details
Discussion: https://postgr.es/m/143A51B2-80B1-4ECD-AF67-F7061377FF63@hotmail.com

Author: Li Japin

Backpatch-through: master
2023-11-01 13:57:29 -04:00
Daniel Gustafsson
0f852cccd9 Fix function name in comment
The name of the function resulting from the macro expansion was
incorrectly stated.

Backpatch to 16 where it was introduced.

Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://postgr.es/m/20231101.172308.1740861597185391383.horikyota.ntt@gmail.com
Backpatch-through: v16
2023-11-01 11:46:30 +01:00
Michael Paquier
fe705ef6fc doc: Expand section related to LWLocks and shared memory
The documentation includes a section describing how to define custom
LWLocks in extensions using the shmem hooks.  However, it has never
mentioned the second, more flexible method based on the following
routines:
- LWLockNewTrancheId() to allocate a tranche ID.
- LWLockRegisterTranche() to associate a name to a tranche ID.
- LWLockInitialize() to initialize a LWLock with a tranche ID.

autoprewarm.c is the only example of extension in the tree that
allocates a LWLock this way.

This commit adds some documentation about all that.  While on it, a
comment is added about the need of AddinShmemInitLock.  This is required
especially for EXEC_BACKEND builds (aka Windows, normally), as per a
remark from Alexander, because backends can execute shmem initialization
paths concurrently.

Author: Aleksander Alekseev, Michael Paquier
Discussion: https://postgr.es/m/CAJ7c6TPKhFgL+54cdTD9yGpG4+sNcyJ+N1GvQqAxgWENAOa3VA@mail.gmail.com
2023-11-01 14:54:13 +09:00
7 changed files with 100 additions and 74 deletions

View File

@ -9729,21 +9729,19 @@ SELECT t1.a, t1.phv, t2.b, t2.phv FROM (SELECT 't1_phv' phv, * FROM fprt1 WHERE
-- test FOR UPDATE; partitionwise join does not apply -- test FOR UPDATE; partitionwise join does not apply
EXPLAIN (COSTS OFF) EXPLAIN (COSTS OFF)
SELECT t1.a, t2.b FROM fprt1 t1 INNER JOIN fprt2 t2 ON (t1.a = t2.b) WHERE t1.a % 25 = 0 ORDER BY 1,2 FOR UPDATE OF t1; SELECT t1.a, t2.b FROM fprt1 t1 INNER JOIN fprt2 t2 ON (t1.a = t2.b) WHERE t1.a % 25 = 0 ORDER BY 1,2 FOR UPDATE OF t1;
QUERY PLAN QUERY PLAN
-------------------------------------------------------------- --------------------------------------------------------
LockRows LockRows
-> Sort -> Nested Loop
Sort Key: t1.a Join Filter: (t1.a = t2.b)
-> Hash Join -> Append
Hash Cond: (t2.b = t1.a) -> Foreign Scan on ftprt1_p1 t1_1
-> Foreign Scan on ftprt1_p2 t1_2
-> Materialize
-> Append -> Append
-> Foreign Scan on ftprt2_p1 t2_1 -> Foreign Scan on ftprt2_p1 t2_1
-> Foreign Scan on ftprt2_p2 t2_2 -> Foreign Scan on ftprt2_p2 t2_2
-> Hash (10 rows)
-> Append
-> Foreign Scan on ftprt1_p1 t1_1
-> Foreign Scan on ftprt1_p2 t1_2
(12 rows)
SELECT t1.a, t2.b FROM fprt1 t1 INNER JOIN fprt2 t2 ON (t1.a = t2.b) WHERE t1.a % 25 = 0 ORDER BY 1,2 FOR UPDATE OF t1; SELECT t1.a, t2.b FROM fprt1 t1 INNER JOIN fprt2 t2 ON (t1.a = t2.b) WHERE t1.a % 25 = 0 ORDER BY 1,2 FOR UPDATE OF t1;
a | b a | b
@ -9778,18 +9776,16 @@ ANALYZE fpagg_tab_p3;
SET enable_partitionwise_aggregate TO false; SET enable_partitionwise_aggregate TO false;
EXPLAIN (COSTS OFF) EXPLAIN (COSTS OFF)
SELECT a, sum(b), min(b), count(*) FROM pagg_tab GROUP BY a HAVING avg(b) < 22 ORDER BY 1; SELECT a, sum(b), min(b), count(*) FROM pagg_tab GROUP BY a HAVING avg(b) < 22 ORDER BY 1;
QUERY PLAN QUERY PLAN
----------------------------------------------------------- -----------------------------------------------------
Sort GroupAggregate
Sort Key: pagg_tab.a Group Key: pagg_tab.a
-> HashAggregate Filter: (avg(pagg_tab.b) < '22'::numeric)
Group Key: pagg_tab.a -> Append
Filter: (avg(pagg_tab.b) < '22'::numeric) -> Foreign Scan on fpagg_tab_p1 pagg_tab_1
-> Append -> Foreign Scan on fpagg_tab_p2 pagg_tab_2
-> Foreign Scan on fpagg_tab_p1 pagg_tab_1 -> Foreign Scan on fpagg_tab_p3 pagg_tab_3
-> Foreign Scan on fpagg_tab_p2 pagg_tab_2 (7 rows)
-> Foreign Scan on fpagg_tab_p3 pagg_tab_3
(9 rows)
-- Plan with partitionwise aggregates is enabled -- Plan with partitionwise aggregates is enabled
SET enable_partitionwise_aggregate TO true; SET enable_partitionwise_aggregate TO true;
@ -9823,34 +9819,32 @@ SELECT a, sum(b), min(b), count(*) FROM pagg_tab GROUP BY a HAVING avg(b) < 22 O
-- Should have all the columns in the target list for the given relation -- Should have all the columns in the target list for the given relation
EXPLAIN (VERBOSE, COSTS OFF) EXPLAIN (VERBOSE, COSTS OFF)
SELECT a, count(t1) FROM pagg_tab t1 GROUP BY a HAVING avg(b) < 22 ORDER BY 1; SELECT a, count(t1) FROM pagg_tab t1 GROUP BY a HAVING avg(b) < 22 ORDER BY 1;
QUERY PLAN QUERY PLAN
------------------------------------------------------------------------ --------------------------------------------------------------------------------------------
Sort Merge Append
Output: t1.a, (count(((t1.*)::pagg_tab)))
Sort Key: t1.a Sort Key: t1.a
-> Append -> GroupAggregate
-> HashAggregate Output: t1.a, count(((t1.*)::pagg_tab))
Output: t1.a, count(((t1.*)::pagg_tab)) Group Key: t1.a
Group Key: t1.a Filter: (avg(t1.b) < '22'::numeric)
Filter: (avg(t1.b) < '22'::numeric) -> Foreign Scan on public.fpagg_tab_p1 t1
-> Foreign Scan on public.fpagg_tab_p1 t1 Output: t1.a, t1.*, t1.b
Output: t1.a, t1.*, t1.b Remote SQL: SELECT a, b, c FROM public.pagg_tab_p1 ORDER BY a ASC NULLS LAST
Remote SQL: SELECT a, b, c FROM public.pagg_tab_p1 -> GroupAggregate
-> HashAggregate Output: t1_1.a, count(((t1_1.*)::pagg_tab))
Output: t1_1.a, count(((t1_1.*)::pagg_tab)) Group Key: t1_1.a
Group Key: t1_1.a Filter: (avg(t1_1.b) < '22'::numeric)
Filter: (avg(t1_1.b) < '22'::numeric) -> Foreign Scan on public.fpagg_tab_p2 t1_1
-> Foreign Scan on public.fpagg_tab_p2 t1_1 Output: t1_1.a, t1_1.*, t1_1.b
Output: t1_1.a, t1_1.*, t1_1.b Remote SQL: SELECT a, b, c FROM public.pagg_tab_p2 ORDER BY a ASC NULLS LAST
Remote SQL: SELECT a, b, c FROM public.pagg_tab_p2 -> GroupAggregate
-> HashAggregate Output: t1_2.a, count(((t1_2.*)::pagg_tab))
Output: t1_2.a, count(((t1_2.*)::pagg_tab)) Group Key: t1_2.a
Group Key: t1_2.a Filter: (avg(t1_2.b) < '22'::numeric)
Filter: (avg(t1_2.b) < '22'::numeric) -> Foreign Scan on public.fpagg_tab_p3 t1_2
-> Foreign Scan on public.fpagg_tab_p3 t1_2 Output: t1_2.a, t1_2.*, t1_2.b
Output: t1_2.a, t1_2.*, t1_2.b Remote SQL: SELECT a, b, c FROM public.pagg_tab_p3 ORDER BY a ASC NULLS LAST
Remote SQL: SELECT a, b, c FROM public.pagg_tab_p3 (23 rows)
(25 rows)
SELECT a, count(t1) FROM pagg_tab t1 GROUP BY a HAVING avg(b) < 22 ORDER BY 1; SELECT a, count(t1) FROM pagg_tab t1 GROUP BY a HAVING avg(b) < 22 ORDER BY 1;
a | count a | count
@ -9866,24 +9860,23 @@ SELECT a, count(t1) FROM pagg_tab t1 GROUP BY a HAVING avg(b) < 22 ORDER BY 1;
-- When GROUP BY clause does not match with PARTITION KEY. -- When GROUP BY clause does not match with PARTITION KEY.
EXPLAIN (COSTS OFF) EXPLAIN (COSTS OFF)
SELECT b, avg(a), max(a), count(*) FROM pagg_tab GROUP BY b HAVING sum(a) < 700 ORDER BY 1; SELECT b, avg(a), max(a), count(*) FROM pagg_tab GROUP BY b HAVING sum(a) < 700 ORDER BY 1;
QUERY PLAN QUERY PLAN
----------------------------------------------------------------- -----------------------------------------------------------
Sort Finalize GroupAggregate
Sort Key: pagg_tab.b Group Key: pagg_tab.b
-> Finalize HashAggregate Filter: (sum(pagg_tab.a) < 700)
Group Key: pagg_tab.b -> Merge Append
Filter: (sum(pagg_tab.a) < 700) Sort Key: pagg_tab.b
-> Append -> Partial GroupAggregate
-> Partial HashAggregate Group Key: pagg_tab.b
Group Key: pagg_tab.b -> Foreign Scan on fpagg_tab_p1 pagg_tab
-> Foreign Scan on fpagg_tab_p1 pagg_tab -> Partial GroupAggregate
-> Partial HashAggregate Group Key: pagg_tab_1.b
Group Key: pagg_tab_1.b -> Foreign Scan on fpagg_tab_p2 pagg_tab_1
-> Foreign Scan on fpagg_tab_p2 pagg_tab_1 -> Partial GroupAggregate
-> Partial HashAggregate Group Key: pagg_tab_2.b
Group Key: pagg_tab_2.b -> Foreign Scan on fpagg_tab_p3 pagg_tab_2
-> Foreign Scan on fpagg_tab_p3 pagg_tab_2 (14 rows)
(15 rows)
-- =================================================================== -- ===================================================================
-- access rights and superuser -- access rights and superuser

View File

@ -57,7 +57,7 @@ PG_MODULE_MAGIC;
#define DEFAULT_FDW_STARTUP_COST 100.0 #define DEFAULT_FDW_STARTUP_COST 100.0
/* Default CPU cost to process 1 row (above and beyond cpu_tuple_cost). */ /* Default CPU cost to process 1 row (above and beyond cpu_tuple_cost). */
#define DEFAULT_FDW_TUPLE_COST 0.01 #define DEFAULT_FDW_TUPLE_COST 0.2
/* If no remote estimates, assume a sort costs 20% extra */ /* If no remote estimates, assume a sort costs 20% extra */
#define DEFAULT_FDW_SORT_MULTIPLIER 1.2 #define DEFAULT_FDW_SORT_MULTIPLIER 1.2

View File

@ -3942,7 +3942,7 @@ RAISE unique_violation USING MESSAGE = 'Duplicate user ID: ' || user_id;
<para> <para>
If no condition name nor SQLSTATE is specified in a If no condition name nor SQLSTATE is specified in a
<command>RAISE EXCEPTION</command> command, the default is to use <command>RAISE EXCEPTION</command> command, the default is to use
<literal>ERRCODE_RAISE_EXCEPTION</literal> (<literal>P0001</literal>). <literal>raise_exception</literal> (<literal>P0001</literal>).
If no message text is specified, the default is to use the condition If no message text is specified, the default is to use the condition
name or SQLSTATE as message text. name or SQLSTATE as message text.
</para> </para>

View File

@ -2222,8 +2222,10 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
</para> </para>
<para> <para>
WAL data is sent as a series of CopyData messages. (This allows WAL data is sent as a series of CopyData messages;
other information to be intermixed; in particular the server can send see <xref linkend="protocol-message-types"/> and <xref
linkend="protocol-message-formats"/> for details.
(This allows other information to be intermixed; in particular the server can send
an ErrorResponse message if it encounters a failure after beginning an ErrorResponse message if it encounters a failure after beginning
to stream.) The payload of each CopyData message from server to the to stream.) The payload of each CopyData message from server to the
client contains a message of one of the following formats: client contains a message of one of the following formats:

View File

@ -3428,6 +3428,29 @@ void RequestNamedLWLockTranche(const char *tranche_name, int num_lwlocks)
<filename>contrib/pg_stat_statements/pg_stat_statements.c</filename> in the <filename>contrib/pg_stat_statements/pg_stat_statements.c</filename> in the
<productname>PostgreSQL</productname> source tree. <productname>PostgreSQL</productname> source tree.
</para> </para>
<para>
There is another, more flexible method of obtaining LWLocks. First,
allocate a <literal>tranche_id</literal> from a shared counter by
calling:
<programlisting>
int LWLockNewTrancheId(void)
</programlisting>
Next, each individual process using the <literal>tranche_id</literal>
should associate it with a <literal>tranche_name</literal> by calling:
<programlisting>
void LWLockRegisterTranche(int tranche_id, const char *tranche_name)
</programlisting>
It is also required to call <function>LWLockInitialize</function> once
per LWLock, passing the <literal>tranche_id</literal> as argument:
<programlisting>
void LWLockInitialize(LWLock *lock, int tranche_id)
</programlisting>
A complete usage example of <function>LWLockNewTrancheId</function>,
<function>LWLockInitialize</function> and
<function>LWLockRegisterTranche</function> can be found in
<filename>contrib/pg_prewarm/autoprewarm.c</filename> in the
<productname>PostgreSQL</productname> source tree.
</para>
<para> <para>
To avoid possible race-conditions, each backend should use the LWLock To avoid possible race-conditions, each backend should use the LWLock
<function>AddinShmemInitLock</function> when connecting to and initializing <function>AddinShmemInitLock</function> when connecting to and initializing
@ -3451,6 +3474,13 @@ if (!ptr)
} }
</programlisting> </programlisting>
</para> </para>
<para>
It is convenient to use <literal>shmem_startup_hook</literal> which allows
placing all the code responsible for initializing shared memory in one
place. When using <literal>shmem_startup_hook</literal> the extension
still needs to acquire <function>AddinShmemInitLock</function> in order to
work properly on all the supported platforms.
</para>
</sect2> </sect2>
<sect2 id="xfunc-addin-wait-events"> <sect2 id="xfunc-addin-wait-events">

View File

@ -78,7 +78,7 @@ PG_STAT_GET_RELENTRY_INT64(ins_since_vacuum)
/* pg_stat_get_live_tuples */ /* pg_stat_get_live_tuples */
PG_STAT_GET_RELENTRY_INT64(live_tuples) PG_STAT_GET_RELENTRY_INT64(live_tuples)
/* pg_stat_get_mods_since_analyze */ /* pg_stat_get_mod_since_analyze */
PG_STAT_GET_RELENTRY_INT64(mod_since_analyze) PG_STAT_GET_RELENTRY_INT64(mod_since_analyze)
/* pg_stat_get_numscans */ /* pg_stat_get_numscans */

View File

@ -14,12 +14,13 @@ $node->start;
# Grab the names of all the parameters that can be listed in the # Grab the names of all the parameters that can be listed in the
# configuration sample file. config_file is an exception, it is not # configuration sample file. config_file is an exception, it is not
# in postgresql.conf.sample but is part of the lists from guc_tables.c. # in postgresql.conf.sample but is part of the lists from guc_tables.c.
# Custom GUCs loaded by extensions are excluded.
my $all_params = $node->safe_psql( my $all_params = $node->safe_psql(
'postgres', 'postgres',
"SELECT name "SELECT name
FROM pg_settings FROM pg_settings
WHERE NOT 'NOT_IN_SAMPLE' = ANY (pg_settings_get_flags(name)) AND WHERE NOT 'NOT_IN_SAMPLE' = ANY (pg_settings_get_flags(name)) AND
name <> 'config_file' name <> 'config_file' AND category <> 'Customized Options'
ORDER BY 1"); ORDER BY 1");
# Note the lower-case conversion, for consistency. # Note the lower-case conversion, for consistency.
my @all_params_array = split("\n", lc($all_params)); my @all_params_array = split("\n", lc($all_params));