Merge branch 'PGPROEE9_6' into mtm-stm

kelvich · kelvich · commit 75f92cd7f346 · 2017-09-15T16:21:03.000+03:00
diff --git a/.ci/build_and_test_world b/.ci/build_and_test_world
@@ -2,7 +2,7 @@
 if [ -z "$TCLCONFIG" ]; then
 [ -x /usr/lib/tcl8.5/tclConfig.sh ] && TCLCONFIG=/usr/lib/tcl8.5
 [ -x /usr/lib/tcl8.6/tclConfig.sh ] && TCLCONFIG=/usr/lib/tcl8.6
-[ -x /usr/lib64/tclConfig.sh ] && TCLCONFIG=/usr/lib64/tclConfig.sh
+[ -f /usr/lib64/tclConfig.sh ] && TCLCONFIG=/usr/lib64
 fi
 [ -n "$TCLCONFIG" ] && export TCLCONFIG
 echo TCLCONFIG=${TCLCONFIG}
diff --git a/.ci/make_test_base b/.ci/make_test_base
@@ -7,11 +7,22 @@ put into postgresql conf.
 
 On success, starts database
 """
-import os,sys,subprocess,glob,re,os.path,time
+import os,sys,subprocess,glob,re,os.path,time,re
 
 if len(sys.argv)!=2:
     print >>sys.stderr,"Usage %s data-directory" % sys.argv[0]
     sys.exit(1)
+    
+def prepare_extlist(value):
+    v = re.sub("[']", '', value)
+    l = re.split("\s*,\s*",v)
+    if "pg_pathman" in l:
+        # remove duplicates and reorder extension list to move pg_pathman to tail
+        nl = sorted(list(set(l)), cmp = lambda a,b: 1 if a=="pg_pathman" else -1)
+        new_value = "'{}'".format(",".join(nl))
+        return new_value
+    else:
+        return value
 
 datadir=sys.argv[1]
 
@@ -56,10 +67,10 @@ for module in glob.glob("contrib/*"):
                         else:
                             addopts[opt]=value
                                 
-if addopts:                     
+if addopts:
     with open(datadir+"/postgresql.conf","a") as f:
         for opt,value in addopts.items():
-            print >> f,"%s=%s"%(opt,value)
+            print >> f,"%s=%s"%(opt,prepare_extlist(value))
 with open("initdb.log","a") as f:
     exitcode=subprocess.call(["pg_ctl","start","-D",datadir,"-l",datadir+"/postmaster.log"],env=env,stdout=f,stderr=subprocess.STDOUT)
 if exitcode:
@@ -73,5 +84,3 @@ while time.time() < failtime:
         sys.exit(0)
 print >>sys.stderr,"Database havent't started in 60 seconds"
 sys.exit(1)
-
-
diff --git a/.ci/run.cmd b/.ci/run.cmd
@@ -1,11 +1,14 @@
 @echo off
-PATH=C:\Windows\system32;C:\Perl64\bin;C:\msys64\usr\bin
+PATH=C:\Windows\system32;C:\Perl64\bin;C:\Program Files\Git\cmd;C:\msys64\usr\bin
 
-IF "%ARCH%"==""	   SET ARCH=X86
-IF "%ARCH%"=="x86" SET ARCH=X86
-IF "%ARCH%"=="x64" SET ARCH=X64
-IF "%SDK%"=="" 	   SET SDK=SDK71
+IF "%ARCH%"==""	     SET ARCH=X86
+IF "%ARCH%"=="x86"   SET ARCH=X86
+IF "%ARCH%"=="x64"   SET ARCH=X64
+IF "%ARCH%"=="amd64" SET ARCH=X64
+IF "%SDK%"=="" 	     SET SDK=SDK71
 
+echo BUILD_ID=%BUILD_ID%
+echo BUILD_NAME=%BUILD_NAME%
 echo ARCH=%ARCH%
 echo SDK=%SDK%
 
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
@@ -4544,13 +4544,16 @@ SELECT * FROM pg_attribute
    <para>
     Another identifier type used by the system is <type>xid</>, or transaction
     (abbreviated <abbrev>xact</>) identifier.  This is the data type of the system columns
-    <structfield>xmin</> and <structfield>xmax</>.  Transaction identifiers are 32-bit quantities.
+    <structfield>xmin</> and <structfield>xmax</>.
+    In <productname>&productname;</productname>, transaction IDs
+    are implemented as 64-bit counters to prevent transaction ID wraparound.
+    For details, see <xref linkend="vacuum-for-wraparound">.
    </para>
 
    <para>
     A third identifier type used by the system is <type>cid</>, or
     command identifier.  This is the data type of the system columns
-    <structfield>cmin</> and <structfield>cmax</>. Command identifiers are also 32-bit quantities.
+    <structfield>cmin</> and <structfield>cmax</>. Command identifiers are 32-bit quantities.
    </para>
 
    <para>
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
@@ -1096,16 +1096,13 @@ CREATE TABLE circles (
    </para>
 
    <para>
-    Transaction identifiers are also 32-bit quantities.  In a
-    long-lived database it is possible for transaction IDs to wrap
-    around.  This is not a fatal problem given appropriate maintenance
-    procedures; see <xref linkend="maintenance"> for details.  It is
-    unwise, however, to depend on the uniqueness of transaction IDs
-    over the long term (more than one billion transactions).
+    In <productname>&productname;</productname>, transaction IDs
+    are implemented as 64-bit counters to prevent transaction ID wraparound.
+    For details, see <xref linkend="vacuum-for-wraparound">.
    </para>
 
    <para>
-    Command identifiers are also 32-bit quantities.  This creates a hard limit
+    Command identifiers are 32-bit quantities.  This creates a hard limit
     of 2<superscript>32</> (4 billion) <acronym>SQL</acronym> commands
     within a single transaction.  In practice this limit is not a
     problem &mdash; note that the limit is on the number of
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
@@ -17198,8 +17198,9 @@ SELECT collation for ('foo' COLLATE "de_DE");
    </table>
 
    <para>
-    The internal transaction ID type (<type>xid</>) is 32 bits wide and
-    wraps around every 4 billion transactions.  However, these functions
+    In <productname>&productname;</productname>, transaction IDs
+    are implemented as 64-bit counters to prevent transaction ID wraparound.
+    The following functions
     export a 64-bit format that is extended with an <quote>epoch</> counter
     so it will not wrap around during the life of an installation.
     The data type used by these functions, <type>txid_snapshot</type>,
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
@@ -405,7 +405,7 @@
     <productname>Postgres Pro Enterprise 9.6</productname> introduced
     64-bit transaction IDs, which are not subject to wraparound and
     do not need modulo-2<superscript>32</> arithmetic to be compared.
-    Each tuple header contain two XIDs, so extending them would lead to
+    Each tuple header contains two XIDs, so extending them would lead to
     high overhead.  For that reason on-page XIDs are still 32-bit, but
     each page's header contains an offset, called <firstterm>epoch</>,
     to which they are added before comparing with each other.
diff --git a/doc/src/sgml/multimaster.sgml b/doc/src/sgml/multimaster.sgml
@@ -857,7 +857,7 @@ pg_ctl -D <replaceable>datadir</replaceable> -l <replaceable>pg.log</replaceable
 <sect3 id="multimaster-guc-variables">
   <title>GUC Variables</title>
 <variablelist>
-  <varlistentry><term><varname>multimaster.node_id</varname>
+  <varlistentry id="multimaster-node-id"><term><varname>multimaster.node_id</varname>
   <indexterm><primary><varname>multimaster.node_id</varname></primary></indexterm></term><listitem><para>
     Node ID &mdash; a unique natural
     number identifying the node of a multi-master cluster. You must
diff --git a/doc/src/sgml/pgpro-scheduler.sgml b/doc/src/sgml/pgpro-scheduler.sgml
@@ -114,7 +114,9 @@ Make sure to create the <filename>pgpro_scheduler</filename> extension for each
           schedule jobs, in the comma-separated format:
         <programlisting>
 <varname>schedule.database</varname> = '<replaceable>database1</>,<replaceable>database2</>'
-</programlisting></para>
+</programlisting>
+         You can omit this step when using <filename>pgpro_scheduler</filename>
+         on a cluster configured with <filename>multimaster</filename>.</para>
       </listitem>
       <listitem>
         <para>
@@ -639,7 +641,7 @@ schedule.cancel_job(<replaceable>job_id</replaceable> <type>bigint</type>);
      </term>
      <listitem>
       <para>
-       Specifies whether the scheduler is enabled on your system.</para>
+       Specifies whether <filename>pgpro_scheduler</filename> is enabled on your system.</para>
        <para>Default: <literal>false</literal>.
       </para>
      </listitem>
@@ -653,7 +655,16 @@ schedule.cancel_job(<replaceable>job_id</replaceable> <type>bigint</type>);
      </term>
      <listitem>
       <para>
-       Specifies the list of databases for which the scheduler is enabled. Database names must be separated by commas.</para><para>Default: empty string.
+       Specifies the databases for which <filename>pgpro_scheduler</filename> is enabled.
+       Database names must be separated by commas.
+      </para>
+      <para>
+        If <filename>pgpro_scheduler</filename> is running on a cluster configured with
+        <filename>multimaster</filename>, the database name is derived from the
+        <xref linkend="multimaster-conn-strings"> variable.
+      </para>
+      <para>
+       Default: empty string.
       </para>
      </listitem>
     </varlistentry>
@@ -666,11 +677,10 @@ schedule.cancel_job(<replaceable>job_id</replaceable> <type>bigint</type>);
      </term>
      <listitem>
       <para>
-      Specifies the name of a schema where the scheduler
-       stores its tables and functions. Normally, you should
-       not change this variable. This
-      variable may be useful if you run <filename>pgpro_scheduler</filename>
-      on a multi-master cluster.</para>
+       Deprecated. Specifies the name of a schema where the scheduler
+       stores its tables and functions.
+       If you need to change the default schema, use <xref linkend="sql-alterextension">.
+      </para>
        <para>Default: <literal>schedule</literal>.
       </para>
      </listitem>
@@ -684,10 +694,18 @@ schedule.cancel_job(<replaceable>job_id</replaceable> <type>bigint</type>);
      </term>
      <listitem>
       <para>
-      Specifies the node name of your <productname>&productname;</productname> instance. Do
-      not change or use this variable if you run a single server configuration. You may need this 
-      variable if you run <filename>pgpro_scheduler</filename>
-      on a multi-master cluster.</para>
+      Specifies the node name of your <productname>&productname;</productname> instance.
+      Do not change or use this variable if you run a single-server cluster configuration.
+      </para>
+      <para>
+      On a cluster configured with <filename>multimaster</filename>, the node name is
+      derived from the <xref linkend="multimaster-node-id"> variable. For example, if
+      <literal>multimaster.node_id = 3</literal>, the <varname>schedule.nodename</>
+      variable is set to <literal>mtm-node-3</>. However, if you explicitly set
+      the <varname>schedule.nodename</> variable by editing the <filename>postgresql.conf</filename>
+      file or running the <command>ALTER</command> command, <filename>pgpro_scheduler</filename>
+      will use the provided value, ignoring the <varname>multimaster.node_id</varname> variable.
+      </para>
        <para>Default: <literal>master</literal>.
       </para>
      </listitem>
@@ -2113,6 +2131,21 @@ schedule.create_job(<parameter>dates</parameter> <type>timestamp with time zone[
          <para>The number of records deleted.</para></listitem></itemizedlist>
      </listitem>
     </varlistentry>
+
+    <varlistentry>
+     <term>
+      <function>schedule.nodename()
+      </function>
+     <indexterm>
+       <primary><function>schedule.nodename()</></primary>
+     </indexterm>
+     </term>
+     <listitem>
+      <para>
+      Returns the current node name.
+      </para>
+     </listitem>
+    </varlistentry>
     </variablelist>
 </sect4>
 <sect4 id="pgpro-scheduler-one-time-job-functions"><title>Functions for Managing One-Time Jobs</title>
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
@@ -509,7 +509,8 @@ EOF
 	# Generate commit_id file
 	# If there is .git rewrite file whenever gitlog succeeds
 	if ( -d ".git" ) {
-		open P,"git log -1 --format='%h' |";
+		my $cmd = "git log -1 --format='%h'";
+		open P,"$cmd |" || confess "Could not open: $cmd\n";
 		my $commit_id = <P>;
 		chomp($commit_id);
 		if (close(P)) {
