|
24 | 24 |
|
25 | 25 | <para> |
26 | 26 | However, if you use BRIN indexes, it may be advisable to reindex them; |
27 | | - see thefirst changelog entry below. |
| 27 | + see thethird changelog entry below. |
28 | 28 | </para> |
29 | 29 |
|
30 | 30 | <para> |
|
40 | 40 |
|
41 | 41 | <listitem> |
42 | 42 | <!-- |
| 43 | +Author: Noah Misch <noah@leadboat.com> |
| 44 | +Branch: master [cd5f2a357] 2023-08-07 06:05:56 -0700 |
| 45 | +Branch: REL_16_STABLE [f53511010] 2023-08-07 06:05:59 -0700 |
| 46 | +Branch: REL_15_STABLE [de494ec14] 2023-08-07 06:06:00 -0700 |
| 47 | +Branch: REL_14_STABLE [d4648a74b] 2023-08-07 06:06:00 -0700 |
| 48 | +Branch: REL_13_STABLE [b1b585e0f] 2023-08-07 06:06:00 -0700 |
| 49 | +Branch: REL_12_STABLE [eb044d8f0] 2023-08-07 06:06:00 -0700 |
| 50 | +Branch: REL_11_STABLE [919ebb023] 2023-08-07 06:06:01 -0700 |
| 51 | +--> |
| 52 | + <para> |
| 53 | + Disallow substituting a schema or owner name into an extension script |
| 54 | + if the name contains a quote, backslash, or dollar sign (Noah Misch) |
| 55 | + </para> |
| 56 | + |
| 57 | + <para> |
| 58 | + This restriction guards against SQL-injection hazards for trusted |
| 59 | + extensions. |
| 60 | + </para> |
| 61 | + |
| 62 | + <para> |
| 63 | + The <productname>PostgreSQL</productname> Project thanks Micah Gate, |
| 64 | + Valerie Woolard, Tim Carey-Smith, and Christoph Berg for reporting |
| 65 | + this problem. |
| 66 | + (CVE-2023-39417) |
| 67 | + </para> |
| 68 | + </listitem> |
| 69 | + |
| 70 | + <listitem> |
| 71 | +<!-- |
| 72 | +Author: Dean Rasheed <dean.a.rasheed@gmail.com> |
| 73 | +Branch: master [c2e08b04c] 2023-08-07 09:28:47 +0100 |
| 74 | +Branch: REL_16_STABLE [67a007dc0] 2023-08-07 09:27:09 +0100 |
| 75 | +Branch: REL_15_STABLE [cb2ae5741] 2023-08-07 09:24:27 +0100 |
| 76 | +--> |
| 77 | + <para> |
| 78 | + Fix <command>MERGE</command> to enforce row security policies |
| 79 | + properly (Dean Rasheed) |
| 80 | + </para> |
| 81 | + |
| 82 | + <para> |
| 83 | + When <command>MERGE</command> performs an <literal>UPDATE</literal> |
| 84 | + action, it should enforce any <literal>UPDATE</literal> or |
| 85 | + <literal>SELECT</literal> RLS policies defined on the target table, |
| 86 | + to be consistent with the way that a plain <command>UPDATE</command> |
| 87 | + with a <literal>WHERE</literal> clause works. Instead it was |
| 88 | + enforcing <literal>INSERT</literal> RLS policies for both |
| 89 | + <literal>INSERT</literal> and <literal>UPDATE</literal> actions. |
| 90 | + </para> |
| 91 | + |
| 92 | + <para> |
| 93 | + In addition, when <command>MERGE</command> performs a <literal>DO |
| 94 | + NOTHING</literal> action, it applied the target table's |
| 95 | + <literal>DELETE</literal> RLS policies to existing rows, even though |
| 96 | + those rows are not being deleted. While it's not a security |
| 97 | + problem, this could result in unwanted errors. |
| 98 | + </para> |
| 99 | + |
| 100 | + <para> |
| 101 | + The <productname>PostgreSQL</productname> Project thanks |
| 102 | + Dean Rasheed for reporting this problem. |
| 103 | + (CVE-2023-39418) |
| 104 | + </para> |
| 105 | + </listitem> |
| 106 | + |
| 107 | + <listitem> |
| 108 | +<!-- |
43 | 109 | Author: Tomas Vondra <tomas.vondra@postgresql.org> |
44 | 110 | Branch: master Release: REL_16_BR [3581cbdcd] 2023-05-19 01:29:44 +0200 |
45 | 111 | Branch: REL_15_STABLE [e18769323] 2023-05-19 00:15:13 +0200 |
@@ -240,6 +306,27 @@ Branch: REL_11_STABLE [f6345f03f] 2023-06-19 13:03:17 +1200 |
240 | 306 |
|
241 | 307 | <listitem> |
242 | 308 | <!-- |
| 309 | +Author: David Rowley <drowley@postgresql.org> |
| 310 | +Branch: master [990c3650c] 2023-08-07 22:14:21 +1200 |
| 311 | +Branch: REL_16_STABLE [ae89129aa] 2023-08-07 22:14:54 +1200 |
| 312 | +Branch: REL_15_STABLE [71662373b] 2023-08-07 22:15:23 +1200 |
| 313 | +Branch: REL_14_STABLE [bf315354e] 2023-08-07 22:15:50 +1200 |
| 314 | +--> |
| 315 | + <para> |
| 316 | + Don't Memoize lateral joins with volatile join conditions |
| 317 | + (Richard Guo) |
| 318 | + </para> |
| 319 | + |
| 320 | + <para> |
| 321 | + Applying Memoize to a sub-plan that contains volatile filter |
| 322 | + conditions is likely to lead to wrong answers. The check to avoid |
| 323 | + doing this missed some cases that can arise when |
| 324 | + using <literal>LATERAL</literal>. |
| 325 | + </para> |
| 326 | + </listitem> |
| 327 | + |
| 328 | + <listitem> |
| 329 | +<!-- |
243 | 330 | Author: Etsuro Fujita <efujita@postgresql.org> |
244 | 331 | Branch: master [6f80a8d9c] 2023-07-28 15:45:00 +0900 |
245 | 332 | Branch: REL_16_STABLE [695f5deb7] 2023-07-28 15:45:01 +0900 |
|