standby that we plan to promote.
     This query needs to be run on each database that includes the failover-enabled
     subscription(s). Note that the table sync slot should be synced to the standby
     server only if the table copy is finished
     (See <xref linkend="catalog-pg-subscription-rel"/>).
     We don't need to ensure that the table sync slots are synced in other scenarios
     as they will either be dropped or re-created on the new primary server in those
     cases.
<programlisting>
/* sub # */ SELECT
               array_agg(quote_literal(slot_name)) AS slots
           FROM
           (
               SELECT CONCAT('pg_', srsubid, '_sync_', srrelid, '_', ctl.system_identifier) AS slot_name
               FROM pg_control_system() ctl, pg_subscription_rel r, pg_subscription s
               WHERE r.srsubstate = 'f' AND s.oid = r.srsubid AND s.subfailover
           );
 slots
-------
 {'pg_16394_sync_16385_7394666715149055164'}
(1 row)
</programlisting></para>
   </step>
   <step performance="required">
    <para>
     Check that the logical replication slots identified above exist on
     the standby server and are ready for failover.
<programlisting>
/* standby # */ SELECT slot_name, (synced AND NOT temporary AND NOT conflicting) AS failover_ready
               FROM pg_replication_slots
               WHERE slot_name IN
                   ('sub1','sub2','sub3', 'pg_16394_sync_16385_7394666715149055164');
  slot_name                                 | failover_ready
--------------------------------------------+----------------
  sub1                                      | t
  sub2                                      | t
  sub3                                      | t
  pg_16394_sync_16385_7394666715149055164   | t
(4 rows)
</programlisting></para>
    </step>
  </procedure>

  <para>
   If all the slots are present on the standby server and the result
   (<literal>failover_ready</literal>) of the above SQL query is true, then
   existing subscriptions can continue subscribing to publications now on the
   new primary server.
  </para>

 </sect1>

 <sect1 id="logical-replication-row-filter">
  <title>Row Filters</title>

  <para>
   By default, all data from all published tables will be replicated to the
   appropriate subscribers. The replicated data can be reduced by using a
   <firstterm>row filter</firstterm>. A user might choose to use row filters
   for behavioral, security or performance reasons. If a published table sets a
   row filter, a row is replicated only if its data satisfies the row filter
   expression. This allows a set of tables to be partially replicated. The row
   filter is defined per table. Use a <literal>WHERE</literal> clause after the
   table name for each published table that requires data to be filtered out.
   The <literal>WHERE</literal> clause must be enclosed by parentheses. See
   <xref linkend="sql-createpublication"/> for details.
  </para>

  <sect2 id="logical-replication-row-filter-rules">
   <title>Row Filter Rules</title>

   <para>
    Row filters are applied <emphasis>before</emphasis> publishing the changes.
    If the row filter evaluates to <literal>false</literal> or <literal>NULL</literal>
    then the row is not replicated. The <literal>WHERE</literal> clause expression
    is evaluated with the same role used for the replication connection (i.e.
    the role specified in the
    <link linkend="sql-createsubscription-params-connection"><literal>CONNECTION</literal></link>
    clause of the <xref linkend="sql-createsubscription"/>). Row filters have
    no effect for <command>TRUNCATE</command> command.
   </para>

  </sect2>

  <sect2 id="logical-replication-row-filter-restrictions">
   <title>Expression Restrictions</title>

   <para>
    The <literal>WHERE</literal> clause allows only simple expressions. It
    cannot contain user-defined functions, operators, types, and collations,
    system column references or non-immutable built-in functions.
   </para>