Revert "Add eager and lazy freezing strategies to VACUUM."

This reverts commit 4d41799261.  Broad
concerns about regressions caused by eager freezing strategy have been
raised.  Whether or not these concerns can be worked through in any time
frame is far from certain.

Discussion: https://postgr.es/m/20230126004347.gepcmyenk2csxrri@awork3.anarazel.de

doc/src/sgml/config.sgml

@@ -9272,36 +9272,6 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
       </listitem>
      </varlistentry>
 
-     <varlistentry id="guc-vacuum-freeze-strategy-threshold" xreflabel="vacuum_freeze_strategy_threshold">
-      <term><varname>vacuum_freeze_strategy_threshold</varname> (<type>integer</type>)
-      <indexterm>
-       <primary><varname>vacuum_freeze_strategy_threshold</varname> configuration parameter</primary>
-      </indexterm>
-      </term>
-      <listitem>
-       <para>
-        Specifies the cutoff storage size that
-        <command>VACUUM</command> should use to determine its freezing
-        strategy.  This is applied by comparing it to the size of the
-        target table's <glossterm linkend="glossary-fork">main
-         fork</glossterm> at the beginning of each <command>VACUUM</command>.
-        Eager freezing strategy is used by <command>VACUUM</command>
-        when the table's main fork size exceeds this value.
-        <command>VACUUM</command> <emphasis>always</emphasis> uses
-        eager freezing strategy when processing <glossterm
-         linkend="glossary-unlogged">unlogged</glossterm> tables,
-        regardless of this setting.  Otherwise <command>VACUUM</command>
-        uses lazy freezing strategy.  For more information see <xref
-         linkend="vacuum-for-wraparound"/>.
-       </para>
-       <para>
-        If this value is specified without units, it is taken as
-        megabytes.  The default is four gigabytes
-        (<literal>4GB</literal>).
-       </para>
-      </listitem>
-     </varlistentry>
-
      <varlistentry id="guc-vacuum-failsafe-age" xreflabel="vacuum_failsafe_age">
       <term><varname>vacuum_failsafe_age</varname> (<type>integer</type>)
       <indexterm>

doc/src/sgml/maintenance.sgml

@@ -478,30 +478,13 @@
    </note>
 
    <para>
-    <xref linkend="guc-vacuum-freeze-strategy-threshold"/> controls
-    <command>VACUUM</command>'s freezing strategy.  The
-    <firstterm>eager freezing strategy</firstterm> makes
-    <command>VACUUM</command> freeze all rows on a page whenever each
-    and every row on the page is considered visible to all current
-    transactions (immediately after dead row versions are removed).
-    Freezing pages early and in batch often spreads out the overhead
-    of freezing over time.  <command>VACUUM</command> consistently
-    avoids allowing unfrozen all-visible pages to build up, improving
-    system level performance stability.  The <firstterm>lazy freezing
-     strategy</firstterm> makes <command>VACUUM</command> determine
-    whether pages should be frozen on the basis of the age of the
-    oldest XID on the page.  Freezing pages lazily sometimes avoids
-    the overhead of freezing that turns out to have been unnecessary
-    because the rows were modified soon after freezing took place.
-   </para>
-
-   <para>
-    <xref linkend="guc-vacuum-freeze-min-age"/> controls how old an
-    XID value has to be before pages with rows bearing that XID are
-    frozen.  This setting is an additional trigger criteria for
-    freezing a page's tuples.  It is used by both freezing strategies,
-    though it typically has little impact when <command>VACUUM</command>
-    uses the eager freezing strategy.
+    <xref linkend="guc-vacuum-freeze-min-age"/>
+    controls how old an XID value has to be before rows bearing that XID will be
+    frozen.  Increasing this setting may avoid unnecessary work if the
+    rows that would otherwise be frozen will soon be modified again,
+    but decreasing this setting increases
+    the number of transactions that can elapse before the table must be
+    vacuumed again.
    </para>
 
    <para>
@@ -523,21 +506,12 @@
     always use its aggressive strategy.
    </para>
 
-   <para>
-    Controlling the overhead of freezing existing all-visible pages
-    during aggressive vacuuming is the goal of the eager freezing
-    strategy.  Increasing <varname>vacuum_freeze_strategy_threshold</varname>
-    may avoid unnecessary work, but it increases the risk of an
-    eventual aggressive vacuum that performs an excessive amount of
-    <quote>catch up</quote> freezing all at once.
-   </para>
-
    <para>
     The maximum time that a table can go unvacuumed is two billion
     transactions minus the <varname>vacuum_freeze_min_age</varname> value at
     the time of the last aggressive vacuum. If it were to go
-    unvacuumed for longer than that, the system could temporarily refuse to
-    allocate new transaction IDs.  To ensure that this never happens,
+    unvacuumed for longer than
+    that, data loss could result.  To ensure that this does not happen,
     autovacuum is invoked on any table that might contain unfrozen rows with
     XIDs older than the age specified by the configuration parameter <xref
     linkend="guc-autovacuum-freeze-max-age"/>.  (This will happen even if
@@ -577,7 +551,7 @@
    </para>
 
    <para>
-    One disadvantage of increasing <varname>autovacuum_freeze_max_age</varname>
+    The sole disadvantage of increasing <varname>autovacuum_freeze_max_age</varname>
     (and <varname>vacuum_freeze_table_age</varname> along with it) is that
     the <filename>pg_xact</filename> and <filename>pg_commit_ts</filename>
     subdirectories of the database cluster will take more space, because it
@@ -864,8 +838,8 @@ vacuum insert threshold = vacuum base insert threshold + vacuum insert scale fac
     For tables which receive <command>INSERT</command> operations but no or
     almost no <command>UPDATE</command>/<command>DELETE</command> operations,
     it may be beneficial to lower the table's
-    <xref linkend="reloption-autovacuum-freeze-strategy-threshold"/>
-    to allow freezing to take place proactively.  The number of obsolete tuples and
+    <xref linkend="reloption-autovacuum-freeze-min-age"/> as this may allow
+    tuples to be frozen by earlier vacuums.  The number of obsolete tuples and
     the number of inserted tuples are obtained from the cumulative statistics system;
     it is a semi-accurate count updated by each <command>UPDATE</command>,
     <command>DELETE</command> and <command>INSERT</command> operation.  (It is

doc/src/sgml/ref/create_table.sgml

@@ -1781,20 +1781,6 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
     </listitem>
    </varlistentry>
 
-   <varlistentry id="reloption-autovacuum-freeze-strategy-threshold" xreflabel="autovacuum_freeze_strategy_threshold">
-    <term><literal>autovacuum_freeze_strategy_threshold</literal>, <literal>toast.autovacuum_freeze_strategy_threshold</literal> (<type>integer</type>)
-    <indexterm>
-     <primary><varname>autovacuum_freeze_strategy_threshold</varname> storage parameter</primary>
-    </indexterm>
-    </term>
-    <listitem>
-     <para>
-      Per-table value for <xref linkend="guc-vacuum-freeze-strategy-threshold"/>
-      parameter.
-     </para>
-    </listitem>
-   </varlistentry>
-
    <varlistentry id="reloption-log-autovacuum-min-duration" xreflabel="log_autovacuum_min_duration">
     <term><literal>log_autovacuum_min_duration</literal>, <literal>toast.log_autovacuum_min_duration</literal> (<type>integer</type>)
     <indexterm>