Skip to content

Commit db9b8b9

Browse files
dmpgprodmpgpro
committed
Merge branch 'REL9_6_STABLE' into PGPRO9_6
2 parents b26b0f0 + 5e1431f commit db9b8b9

File tree

26 files changed

+471
-137
lines changed

26 files changed

+471
-137
lines changed

‎doc/src/sgml/config.sgml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2614,7 +2614,7 @@ include_dir 'conf.d'
26142614
<listitem>
26152615
<para>
26162616
Maximum time between automatic WAL checkpoints, in seconds.
2617-
The valid range is between 30 seconds and one hour.
2617+
The valid range is between 30 seconds and one day.
26182618
The default is five minutes (<literal>5min</>).
26192619
Increasing this parameter can increase the amount of time needed
26202620
for crash recovery.

‎doc/src/sgml/ddl.sgml

Lines changed: 22 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -1629,7 +1629,7 @@ CREATE POLICY account_managers ON accounts TO managers
16291629

16301630
<programlisting>
16311631
CREATE POLICY user_policy ON users
1632-
USING (user = current_user);
1632+
USING (user_name = current_user);
16331633
</programlisting>
16341634

16351635
<para>
@@ -1642,7 +1642,7 @@ CREATE POLICY user_policy ON users
16421642
<programlisting>
16431643
CREATE POLICY user_policy ON users
16441644
USING (true)
1645-
WITH CHECK (user = current_user);
1645+
WITH CHECK (user_name = current_user);
16461646
</programlisting>
16471647

16481648
<para>
@@ -1662,7 +1662,7 @@ CREATE POLICY user_policy ON users
16621662
<programlisting>
16631663
-- Simple passwd-file based example
16641664
CREATE TABLE passwd (
1665-
username text UNIQUE NOT NULL,
1665+
user_name text UNIQUE NOT NULL,
16661666
pwhash text,
16671667
uid int PRIMARY KEY,
16681668
gid int NOT NULL,
@@ -1696,17 +1696,17 @@ CREATE POLICY all_view ON passwd FOR SELECT USING (true);
16961696
-- Normal users can update their own records, but
16971697
-- limit which shells a normal user is allowed to set
16981698
CREATE POLICY user_mod ON passwd FOR UPDATE
1699-
USING (current_user = username)
1699+
USING (current_user = user_name)
17001700
WITH CHECK (
1701-
current_user = username AND
1701+
current_user = user_name AND
17021702
shell IN ('/bin/bash','/bin/sh','/bin/dash','/bin/zsh','/bin/tcsh')
17031703
);
17041704

17051705
-- Allow admin all normal rights
17061706
GRANT SELECT, INSERT, UPDATE, DELETE ON passwd TO admin;
17071707
-- Users only get select access on public columns
17081708
GRANT SELECT
1709-
(username, uid, gid, real_name, home_phone, extra_info, home_dir, shell)
1709+
(user_name, uid, gid, real_name, home_phone, extra_info, home_dir, shell)
17101710
ON passwd TO public;
17111711
-- Allow users to update certain columns
17121712
GRANT UPDATE
@@ -1725,38 +1725,38 @@ GRANT UPDATE
17251725
postgres=&gt; set role admin;
17261726
SET
17271727
postgres=&gt; table passwd;
1728-
username | pwhash | uid | gid | real_name | home_phone | extra_info | home_dir | shell
1729-
----------+--------+-----+-----+-----------+--------------+------------+-------------+-----------
1730-
admin | xxx | 0 | 0 | Admin | 111-222-3333 | | /root | /bin/dash
1731-
bob | xxx | 1 | 1 | Bob | 123-456-7890 | | /home/bob | /bin/zsh
1732-
alice | xxx | 2 | 1 | Alice | 098-765-4321 | | /home/alice | /bin/zsh
1728+
user_name | pwhash | uid | gid | real_name | home_phone | extra_info | home_dir | shell
1729+
-----------+--------+-----+-----+-----------+--------------+------------+-------------+-----------
1730+
admin | xxx | 0 | 0 | Admin | 111-222-3333 | | /root | /bin/dash
1731+
bob | xxx | 1 | 1 | Bob | 123-456-7890 | | /home/bob | /bin/zsh
1732+
alice | xxx | 2 | 1 | Alice | 098-765-4321 | | /home/alice | /bin/zsh
17331733
(3 rows)
17341734

17351735
-- Test what Alice is able to do
17361736
postgres=&gt; set role alice;
17371737
SET
17381738
postgres=&gt; table passwd;
17391739
ERROR: permission denied for relation passwd
1740-
postgres=&gt; select username,real_name,home_phone,extra_info,home_dir,shell from passwd;
1741-
username | real_name | home_phone | extra_info | home_dir | shell
1742-
----------+-----------+--------------+------------+-------------+-----------
1743-
admin | Admin | 111-222-3333 | | /root | /bin/dash
1744-
bob | Bob | 123-456-7890 | | /home/bob | /bin/zsh
1745-
alice | Alice | 098-765-4321 | | /home/alice | /bin/zsh
1740+
postgres=&gt; select user_name,real_name,home_phone,extra_info,home_dir,shell from passwd;
1741+
user_name | real_name | home_phone | extra_info | home_dir | shell
1742+
-----------+-----------+--------------+------------+-------------+-----------
1743+
admin | Admin | 111-222-3333 | | /root | /bin/dash
1744+
bob | Bob | 123-456-7890 | | /home/bob | /bin/zsh
1745+
alice | Alice | 098-765-4321 | | /home/alice | /bin/zsh
17461746
(3 rows)
17471747

1748-
postgres=&gt; update passwd set username = 'joe';
1748+
postgres=&gt; update passwd set user_name = 'joe';
17491749
ERROR: permission denied for relation passwd
17501750
-- Alice is allowed to change her own real_name, but no others
17511751
postgres=&gt; update passwd set real_name = 'Alice Doe';
17521752
UPDATE 1
1753-
postgres=&gt; update passwd set real_name = 'John Doe' where username = 'admin';
1753+
postgres=&gt; update passwd set real_name = 'John Doe' where user_name = 'admin';
17541754
UPDATE 0
17551755
postgres=&gt; update passwd set shell = '/bin/xx';
17561756
ERROR: new row violates WITH CHECK OPTION for "passwd"
17571757
postgres=&gt; delete from passwd;
17581758
ERROR: permission denied for relation passwd
1759-
postgres=&gt; insert into passwd (username) values ('xxx');
1759+
postgres=&gt; insert into passwd (user_name) values ('xxx');
17601760
ERROR: permission denied for relation passwd
17611761
-- Alice can change her own password; RLS silently prevents updating other rows
17621762
postgres=&gt; update passwd set pwhash = 'abc';
@@ -2055,7 +2055,7 @@ DROP SCHEMA myschema CASCADE;
20552055
(since this is one of the ways to restrict the activities of your
20562056
users to well-defined namespaces). The syntax for that is:
20572057
<programlisting>
2058-
CREATE SCHEMA <replaceable>schemaname</replaceable> AUTHORIZATION <replaceable>username</replaceable>;
2058+
CREATE SCHEMA <replaceable>schema_name</replaceable> AUTHORIZATION <replaceable>user_name</replaceable>;
20592059
</programlisting>
20602060
You can even omit the schema name, in which case the schema name
20612061
will be the same as the user name. See <xref
@@ -2344,7 +2344,7 @@ REVOKE CREATE ON SCHEMA public FROM PUBLIC;
23442344
implements only the basic schema support specified in the
23452345
standard. Therefore, many users consider qualified names to
23462346
really consist of
2347-
<literal><replaceable>username</>.<replaceable>tablename</></literal>.
2347+
<literal><replaceable>user_name</>.<replaceable>table_name</></literal>.
23482348
This is how <productname>PostgreSQL</productname> will effectively
23492349
behave if you create a per-user schema for every user.
23502350
</para>

‎doc/src/sgml/extend.sgml

Lines changed: 20 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -335,11 +335,13 @@
335335
by <application>pg_dump</>. Such a change is usually only sensible if
336336
you concurrently make the same change in the extension's script file.
337337
(But there are special provisions for tables containing configuration
338-
data; see below.)
338+
data; see <xref linkend="extend-extensions-config-tables">.)
339+
In production situations, it's generally better to create an extension
340+
update script to perform changes to extension member objects.
339341
</para>
340342

341343
<para>
342-
The extension script may set privileges on objects which are part of the
344+
The extension script may set privileges on objects that are part of the
343345
extension via <command>GRANT</command> and <command>REVOKE</command>
344346
statements. The final set of privileges for each object (if any are set)
345347
will be stored in the
@@ -453,9 +455,11 @@
453455
<term><varname>comment</varname> (<type>string</type>)</term>
454456
<listitem>
455457
<para>
456-
A comment (any string) about the extension. Alternatively,
457-
the comment can be set by means of the <xref linkend="sql-comment">
458-
command in the script file.
458+
A comment (any string) about the extension. The comment is applied
459+
when initially creating an extension, but not during extension updates
460+
(since that might override user-added comments). Alternatively,
461+
the extension's comment can be set by writing
462+
a <xref linkend="sql-comment"> command in the script file.
459463
</para>
460464
</listitem>
461465
</varlistentry>
@@ -518,7 +522,7 @@
518522
its contained objects into a different schema after initial creation
519523
of the extension. The default is <literal>false</>, i.e. the
520524
extension is not relocatable.
521-
See below for more information.
525+
See <xref linkend="extend-extensions-relocation"> for more information.
522526
</para>
523527
</listitem>
524528
</varlistentry>
@@ -529,7 +533,10 @@
529533
<para>
530534
This parameter can only be set for non-relocatable extensions.
531535
It forces the extension to be loaded into exactly the named schema
532-
and not any other. See below for more information.
536+
and not any other.
537+
The <varname>schema</varname> parameter is consulted only when
538+
initially creating an extension, not during extension updates.
539+
See <xref linkend="extend-extensions-relocation"> for more information.
533540
</para>
534541
</listitem>
535542
</varlistentry>
@@ -562,7 +569,8 @@
562569
comments) by the extension mechanism. This provision is commonly used
563570
to throw an error if the script file is fed to <application>psql</>
564571
rather than being loaded via <command>CREATE EXTENSION</> (see example
565-
script below). Without that, users might accidentally load the
572+
script in <xref linkend="extend-extensions-example">).
573+
Without that, users might accidentally load the
566574
extension's contents as <quote>loose</> objects rather than as an
567575
extension, a state of affairs that's a bit tedious to recover from.
568576
</para>
@@ -580,7 +588,7 @@
580588

581589
</sect2>
582590

583-
<sect2>
591+
<sect2 id="extend-extensions-relocation">
584592
<title>Extension Relocatability</title>
585593

586594
<para>
@@ -678,7 +686,7 @@ SET LOCAL search_path TO @extschema@;
678686
</para>
679687
</sect2>
680688

681-
<sect2>
689+
<sect2 id="extend-extensions-config-tables">
682690
<title>Extension Configuration Tables</title>
683691

684692
<para>
@@ -762,7 +770,7 @@ SELECT pg_catalog.pg_extension_config_dump('my_config', 'WHERE NOT standard_entr
762770
out but the dump will not be able to be restored directly and user
763771
intervention will be required.
764772
</para>
765-
773+
766774
<para>
767775
Sequences associated with <type>serial</> or <type>bigserial</> columns
768776
need to be directly marked to dump their state. Marking their parent
@@ -877,7 +885,7 @@ SELECT * FROM pg_extension_update_paths('<replaceable>extension_name</>');
877885
</para>
878886
</sect2>
879887

880-
<sect2>
888+
<sect2 id="extend-extensions-example">
881889
<title>Extension Example</title>
882890

883891
<para>

‎doc/src/sgml/func.sgml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9460,7 +9460,7 @@ CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple
94609460
<literal><function>ts_filter(<replaceable class="PARAMETER">vector</replaceable> <type>tsvector</>, <replaceable class="PARAMETER">weights</replaceable> <type>"char"[]</>)</function></literal>
94619461
</entry>
94629462
<entry><type>tsvector</type></entry>
9463-
<entry>Select only elements with given <replaceable class="PARAMETER">weights</replaceable> from <replaceable class="PARAMETER">vector</replaceable></entry>
9463+
<entry>select only elements with given <replaceable class="PARAMETER">weights</replaceable> from <replaceable class="PARAMETER">vector</replaceable></entry>
94649464
<entry><literal>ts_filter('fat:2,4 cat:3b rat:5A'::tsvector, '{a,b}')</literal></entry>
94659465
<entry><literal>'cat':3B 'rat':5A</literal></entry>
94669466
</row>

‎doc/src/sgml/maintenance.sgml

Lines changed: 35 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -389,7 +389,8 @@
389389
</indexterm>
390390

391391
<para>
392-
<productname>PostgreSQL</productname>'s MVCC transaction semantics
392+
<productname>PostgreSQL</productname>'s
393+
<link linkend="mvcc-intro">MVCC</link> transaction semantics
393394
depend on being able to compare transaction ID (<acronym>XID</>)
394395
numbers: a row version with an insertion XID greater than the current
395396
transaction's XID is <quote>in the future</> and should not be visible
@@ -407,13 +408,10 @@
407408
<para>
408409
The reason that periodic vacuuming solves the problem is that
409410
<command>VACUUM</> will mark rows as <emphasis>frozen</>, indicating that
410-
they were inserted by a transaction which committed sufficiently far in
411-
the past that the effects of the inserting transaction is certain to be
412-
visible, from an MVCC perspective, to all current and future transactions.
413-
<productname>PostgreSQL</> reserves a special XID,
414-
<literal>FrozenTransactionId</>, which does not follow the normal XID
415-
comparison rules and is always considered older
416-
than every normal XID. Normal XIDs are
411+
they were inserted by a transaction that committed sufficiently far in
412+
the past that the effects of the inserting transaction are certain to be
413+
visible to all current and future transactions.
414+
Normal XIDs are
417415
compared using modulo-2<superscript>32</> arithmetic. This means
418416
that for every normal XID, there are two billion XIDs that are
419417
<quote>older</> and two billion that are <quote>newer</>; another
@@ -423,16 +421,40 @@
423421
the next two billion transactions, no matter which normal XID we are
424422
talking about. If the row version still exists after more than two billion
425423
transactions, it will suddenly appear to be in the future. To
426-
prevent this, frozen row versions are treated as if the inserting XID were
424+
prevent this, <productname>PostgreSQL</> reserves a special XID,
425+
<literal>FrozenTransactionId</>, which does not follow the normal XID
426+
comparison rules and is always considered older
427+
than every normal XID.
428+
Frozen row versions are treated as if the inserting XID were
427429
<literal>FrozenTransactionId</>, so that they will appear to be
428430
<quote>in the past</> to all normal transactions regardless of wraparound
429431
issues, and so such row versions will be valid until deleted, no matter
430432
how long that is.
431433
</para>
432434

435+
<note>
436+
<para>
437+
In <productname>PostgreSQL</> versions before 9.4, freezing was
438+
implemented by actually replacing a row's insertion XID
439+
with <literal>FrozenTransactionId</>, which was visible in the
440+
row's <structname>xmin</> system column. Newer versions just set a flag
441+
bit, preserving the row's original <structname>xmin</> for possible
442+
forensic use. However, rows with <structname>xmin</> equal
443+
to <literal>FrozenTransactionId</> (2) may still be found
444+
in databases <application>pg_upgrade</>'d from pre-9.4 versions.
445+
</para>
446+
<para>
447+
Also, system catalogs may contain rows with <structname>xmin</> equal
448+
to <literal>BootstrapTransactionId</> (1), indicating that they were
449+
inserted during the first phase of <application>initdb</>.
450+
Like <literal>FrozenTransactionId</>, this special XID is treated as
451+
older than every normal XID.
452+
</para>
453+
</note>
454+
433455
<para>
434456
<xref linkend="guc-vacuum-freeze-min-age">
435-
controls how old an XID value has to be before its row version will be
457+
controls how old an XID value has to be before rows bearing that XID will be
436458
frozen. Increasing this setting may avoid unnecessary work if the
437459
rows that would otherwise be frozen will soon be modified again,
438460
but decreasing this setting increases
@@ -442,10 +464,10 @@
442464

443465
<para>
444466
<command>VACUUM</> uses the <link linkend="storage-vm">visibility map</>
445-
to determine which pages of a relation must be scanned. Normally, it
446-
will skips pages that don't have any dead row versions even if those pages
467+
to determine which pages of a table must be scanned. Normally, it
468+
will skip pages that don't have any dead row versions even if those pages
447469
might still have row versions with old XID values. Therefore, normal
448-
scans won't succeed in freezing every row version in the table.
470+
<command>VACUUM</>s won't always freeze every old row version in the table.
449471
Periodically, <command>VACUUM</> will perform an <firstterm>aggressive
450472
vacuum</>, skipping only those pages which contain neither dead rows nor
451473
any unfrozen XID or MXID values.

‎doc/src/sgml/pgtrgm.sgml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -104,7 +104,7 @@
104104
the second string a most similar word not a most similar substring. The
105105
range of the result is zero (indicating that the two strings are
106106
completely dissimilar) to one (indicating that the first string is
107-
identical to one of the word of the second string).
107+
identical to one of the words of the second string).
108108
</entry>
109109
</row>
110110
<row>

0 commit comments

Comments
 (0)