<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/postgresql.git/src/include/replication, branch master</title>
<subtitle>git.postgresql.org: git/postgresql.git
</subtitle>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/'/>
<entry>
<title>Fix invalid memory access during the shutdown of the parallel apply worker.</title>
<updated>2023-05-09T03:58:06+00:00</updated>
<author>
<name>Amit Kapila</name>
<email>akapila@postgresql.org</email>
</author>
<published>2023-05-09T03:58:06+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=3d144c6c86025272e1711539f5fafb6fb85c4feb'/>
<id>3d144c6c86025272e1711539f5fafb6fb85c4feb</id>
<content type='text'>
The callback function pa_shutdown() accesses MyLogicalRepWorker which may
not be initialized if there is an error during the initialization of the
parallel apply worker. The other problem is that by the time it is invoked
even after the initialization of the worker, the MyLogicalRepWorker will
be reset by another callback logicalrep_worker_onexit. So, it won't have
the required information.

To fix this, register the shutdown callback after we are attached to the
worker slot.

After this fix, we observed another issue which is that sometimes the
leader apply worker tries to receive the message from the error queue that
might already be detached by the parallel apply worker leading to an
error. To prevent such an error, we ensure that the leader apply worker
detaches from the parallel apply worker's error queue before stopping it.

Reported-by: Sawada Masahiko
Author: Hou Zhijie
Reviewed-by: Sawada Masahiko, Amit Kapila
Discussion: https://postgr.es/m/CAD21AoDo+yUwNq6nTrvE2h9bB2vZfcag=jxWc7QxuWCmkDAqcA@mail.gmail.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The callback function pa_shutdown() accesses MyLogicalRepWorker which may
not be initialized if there is an error during the initialization of the
parallel apply worker. The other problem is that by the time it is invoked
even after the initialization of the worker, the MyLogicalRepWorker will
be reset by another callback logicalrep_worker_onexit. So, it won't have
the required information.

To fix this, register the shutdown callback after we are attached to the
worker slot.

After this fix, we observed another issue which is that sometimes the
leader apply worker tries to receive the message from the error queue that
might already be detached by the parallel apply worker leading to an
error. To prevent such an error, we ensure that the leader apply worker
detaches from the parallel apply worker's error queue before stopping it.

Reported-by: Sawada Masahiko
Author: Hou Zhijie
Reviewed-by: Sawada Masahiko, Amit Kapila
Discussion: https://postgr.es/m/CAD21AoDo+yUwNq6nTrvE2h9bB2vZfcag=jxWc7QxuWCmkDAqcA@mail.gmail.com
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix assertion failure in apply worker.</title>
<updated>2023-05-03T04:47:49+00:00</updated>
<author>
<name>Amit Kapila</name>
<email>akapila@postgresql.org</email>
</author>
<published>2023-05-03T04:43:13+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=de63f8dadee4afa152ce177fd3c562d47373a728'/>
<id>de63f8dadee4afa152ce177fd3c562d47373a728</id>
<content type='text'>
During exit, the logical replication apply worker tries to release session
level locks, if any. However, if the apply worker exits due to an error
before its connection is initialized, trying to release locks can lead to
assertion failure. The locks will be acquired once the worker is
initialized, so we don't need to release them till the worker
initialization is complete.

Reported-by: Alexander Lakhin
Author: Hou Zhijie based on inputs from Sawada Masahiko and Amit Kapila
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/2185d65f-5aae-3efa-c48f-fb42b173ef5c@gmail.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
During exit, the logical replication apply worker tries to release session
level locks, if any. However, if the apply worker exits due to an error
before its connection is initialized, trying to release locks can lead to
assertion failure. The locks will be acquired once the worker is
initialized, so we don't need to release them till the worker
initialization is complete.

Reported-by: Alexander Lakhin
Author: Hou Zhijie based on inputs from Sawada Masahiko and Amit Kapila
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/2185d65f-5aae-3efa-c48f-fb42b173ef5c@gmail.com
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix some typos and some incorrectly duplicated words</title>
<updated>2023-04-18T02:03:49+00:00</updated>
<author>
<name>David Rowley</name>
<email>drowley@postgresql.org</email>
</author>
<published>2023-04-18T02:03:30+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=eef231e8161eb8031a928fe48134ef25ab81fe5e'/>
<id>eef231e8161eb8031a928fe48134ef25ab81fe5e</id>
<content type='text'>
Author: Justin Pryzby
Reviewed-by: David Rowley
Discussion: https://postgr.es/m/ZD3D1QxoccnN8A1V@telsasoft.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Author: Justin Pryzby
Reviewed-by: David Rowley
Discussion: https://postgr.es/m/ZD3D1QxoccnN8A1V@telsasoft.com
</pre>
</div>
</content>
</entry>
<entry>
<title>Harmonize some more function parameter names.</title>
<updated>2023-04-13T17:15:20+00:00</updated>
<author>
<name>Peter Geoghegan</name>
<email>pg@bowt.ie</email>
</author>
<published>2023-04-13T17:15:20+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=d6f0f95a6bb7fa43731c6db83226a3c574041659'/>
<id>d6f0f95a6bb7fa43731c6db83226a3c574041659</id>
<content type='text'>
Make sure that function declarations use names that exactly match the
corresponding names from function definitions in a few places.  These
inconsistencies were all introduced relatively recently, after the code
base had parameter name mismatches fixed in bulk (see commits starting
with commits 4274dc22 and 035ce1fe).

pg_bsd_indent still has a couple of similar inconsistencies, which I
(pgeoghegan) have left untouched for now.

Like all earlier commits that cleaned up function parameter names, this
commit was written with help from clang-tidy.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Make sure that function declarations use names that exactly match the
corresponding names from function definitions in a few places.  These
inconsistencies were all introduced relatively recently, after the code
base had parameter name mismatches fixed in bulk (see commits starting
with commits 4274dc22 and 035ce1fe).

pg_bsd_indent still has a couple of similar inconsistencies, which I
(pgeoghegan) have left untouched for now.

Like all earlier commits that cleaned up function parameter names, this
commit was written with help from clang-tidy.
</pre>
</div>
</content>
</entry>
<entry>
<title>For cascading replication, wake physical and logical walsenders separately</title>
<updated>2023-04-08T08:06:00+00:00</updated>
<author>
<name>Andres Freund</name>
<email>andres@anarazel.de</email>
</author>
<published>2023-04-08T07:24:24+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=e101dfac3a53c20bfbf1ca85d30a368c2954facf'/>
<id>e101dfac3a53c20bfbf1ca85d30a368c2954facf</id>
<content type='text'>
Physical walsenders can't send data until it's been flushed; logical
walsenders can't decode and send data until it's been applied. On the
standby, the WAL is flushed first, which will only wake up physical
walsenders; and then applied, which will only wake up logical
walsenders.

Previously, all walsenders were awakened when the WAL was flushed. That
was fine for logical walsenders on the primary; but on the standby the
flushed WAL would have been not applied yet, so logical walsenders were
awakened too early.

Per idea from Jeff Davis and Amit Kapila.

Author: "Drouvot, Bertrand" &lt;bertranddrouvot.pg@gmail.com&gt;
Reviewed-By: Jeff Davis &lt;pgsql@j-davis.com&gt;
Reviewed-By: Robert Haas &lt;robertmhaas@gmail.com&gt;
Reviewed-by: Amit Kapila &lt;amit.kapila16@gmail.com&gt;
Reviewed-by: Masahiko Sawada &lt;sawada.mshk@gmail.com&gt;
Discussion: https://postgr.es/m/CAA4eK1+zO5LUeisabX10c81LU-fWMKO4M9Wyg1cdkbW7Hqh6vQ@mail.gmail.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Physical walsenders can't send data until it's been flushed; logical
walsenders can't decode and send data until it's been applied. On the
standby, the WAL is flushed first, which will only wake up physical
walsenders; and then applied, which will only wake up logical
walsenders.

Previously, all walsenders were awakened when the WAL was flushed. That
was fine for logical walsenders on the primary; but on the standby the
flushed WAL would have been not applied yet, so logical walsenders were
awakened too early.

Per idea from Jeff Davis and Amit Kapila.

Author: "Drouvot, Bertrand" &lt;bertranddrouvot.pg@gmail.com&gt;
Reviewed-By: Jeff Davis &lt;pgsql@j-davis.com&gt;
Reviewed-By: Robert Haas &lt;robertmhaas@gmail.com&gt;
Reviewed-by: Amit Kapila &lt;amit.kapila16@gmail.com&gt;
Reviewed-by: Masahiko Sawada &lt;sawada.mshk@gmail.com&gt;
Discussion: https://postgr.es/m/CAA4eK1+zO5LUeisabX10c81LU-fWMKO4M9Wyg1cdkbW7Hqh6vQ@mail.gmail.com
</pre>
</div>
</content>
</entry>
<entry>
<title>Support invalidating replication slots due to horizon and wal_level</title>
<updated>2023-04-08T05:40:27+00:00</updated>
<author>
<name>Andres Freund</name>
<email>andres@anarazel.de</email>
</author>
<published>2023-04-08T05:40:27+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=be87200efd9308ccfe217ce8828f316e93e370da'/>
<id>be87200efd9308ccfe217ce8828f316e93e370da</id>
<content type='text'>
Needed for logical decoding on a standby. Slots need to be invalidated because
of the horizon if rows required for logical decoding are removed. If the
primary's wal_level is lowered from 'logical', logical slots on the standby
need to be invalidated.

The new invalidation methods will be used in a subsequent commit.

Logical slots that have been invalidated can be identified via the new
pg_replication_slots.conflicting column.

See 6af1793954e for an overall design of logical decoding on a standby.

Bumps catversion for the addition of the new pg_replication_slots column.

Author: "Drouvot, Bertrand" &lt;bertranddrouvot.pg@gmail.com&gt;
Author: Andres Freund &lt;andres@anarazel.de&gt;
Author: Amit Khandekar &lt;amitdkhan.pg@gmail.com&gt; (in an older version)
Reviewed-by: "Drouvot, Bertrand" &lt;bertranddrouvot.pg@gmail.com&gt;
Reviewed-by: Andres Freund &lt;andres@anarazel.de&gt;
Reviewed-by: Robert Haas &lt;robertmhaas@gmail.com&gt;
Reviewed-by: Fabrízio de Royes Mello &lt;fabriziomello@gmail.com&gt;
Reviewed-by: Bharath Rupireddy &lt;bharath.rupireddyforpostgres@gmail.com&gt;
Reviewed-by: Amit Kapila &lt;amit.kapila16@gmail.com&gt;
Reviewed-by: Melanie Plageman &lt;melanieplageman@gmail.com&gt;
Reviewed-by: Alvaro Herrera &lt;alvherre@alvh.no-ip.org&gt;
Discussion: https://postgr.es/m/20230407075009.igg7be27ha2htkbt@awork3.anarazel.de
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Needed for logical decoding on a standby. Slots need to be invalidated because
of the horizon if rows required for logical decoding are removed. If the
primary's wal_level is lowered from 'logical', logical slots on the standby
need to be invalidated.

The new invalidation methods will be used in a subsequent commit.

Logical slots that have been invalidated can be identified via the new
pg_replication_slots.conflicting column.

See 6af1793954e for an overall design of logical decoding on a standby.

Bumps catversion for the addition of the new pg_replication_slots column.

Author: "Drouvot, Bertrand" &lt;bertranddrouvot.pg@gmail.com&gt;
Author: Andres Freund &lt;andres@anarazel.de&gt;
Author: Amit Khandekar &lt;amitdkhan.pg@gmail.com&gt; (in an older version)
Reviewed-by: "Drouvot, Bertrand" &lt;bertranddrouvot.pg@gmail.com&gt;
Reviewed-by: Andres Freund &lt;andres@anarazel.de&gt;
Reviewed-by: Robert Haas &lt;robertmhaas@gmail.com&gt;
Reviewed-by: Fabrízio de Royes Mello &lt;fabriziomello@gmail.com&gt;
Reviewed-by: Bharath Rupireddy &lt;bharath.rupireddyforpostgres@gmail.com&gt;
Reviewed-by: Amit Kapila &lt;amit.kapila16@gmail.com&gt;
Reviewed-by: Melanie Plageman &lt;melanieplageman@gmail.com&gt;
Reviewed-by: Alvaro Herrera &lt;alvherre@alvh.no-ip.org&gt;
Discussion: https://postgr.es/m/20230407075009.igg7be27ha2htkbt@awork3.anarazel.de
</pre>
</div>
</content>
</entry>
<entry>
<title>Replace replication slot's invalidated_at LSN with an enum</title>
<updated>2023-04-08T04:47:25+00:00</updated>
<author>
<name>Andres Freund</name>
<email>andres@anarazel.de</email>
</author>
<published>2023-04-08T04:47:25+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=15f8203a5975d6b9b78e2c64e213ed964b50c044'/>
<id>15f8203a5975d6b9b78e2c64e213ed964b50c044</id>
<content type='text'>
This is mainly useful because the upcoming logical-decoding-on-standby feature
adds further reasons for invalidating slots, and we don't want to end up with
multiple invalidated_* fields, or check different attributes.

Eventually we should consider not resetting restart_lsn when invalidating a
slot due to max_slot_wal_keep_size. But that's a user visible change, so left
for later.

Increases SLOT_VERSION, due to the changed field (with a different alignment,
no less).

Reviewed-by: "Drouvot, Bertrand" &lt;bertranddrouvot.pg@gmail.com&gt;
Reviewed-by: Alvaro Herrera &lt;alvherre@alvh.no-ip.org&gt;
Reviewed-by: Melanie Plageman &lt;melanieplageman@gmail.com&gt;
Discussion: https://postgr.es/m/20230407075009.igg7be27ha2htkbt@awork3.anarazel.de
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is mainly useful because the upcoming logical-decoding-on-standby feature
adds further reasons for invalidating slots, and we don't want to end up with
multiple invalidated_* fields, or check different attributes.

Eventually we should consider not resetting restart_lsn when invalidating a
slot due to max_slot_wal_keep_size. But that's a user visible change, so left
for later.

Increases SLOT_VERSION, due to the changed field (with a different alignment,
no less).

Reviewed-by: "Drouvot, Bertrand" &lt;bertranddrouvot.pg@gmail.com&gt;
Reviewed-by: Alvaro Herrera &lt;alvherre@alvh.no-ip.org&gt;
Reviewed-by: Melanie Plageman &lt;melanieplageman@gmail.com&gt;
Discussion: https://postgr.es/m/20230407075009.igg7be27ha2htkbt@awork3.anarazel.de
</pre>
</div>
</content>
</entry>
<entry>
<title>Add new predefined role pg_create_subscription.</title>
<updated>2023-03-30T15:37:19+00:00</updated>
<author>
<name>Robert Haas</name>
<email>rhaas@postgresql.org</email>
</author>
<published>2023-03-30T15:37:19+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=c3afe8cf5a1e465bd71e48e4bc717f5bfdc7a7d6'/>
<id>c3afe8cf5a1e465bd71e48e4bc717f5bfdc7a7d6</id>
<content type='text'>
This role can be granted to non-superusers to allow them to issue
CREATE SUBSCRIPTION. The non-superuser must additionally have CREATE
permissions on the database in which the subscription is to be
created.

Most forms of ALTER SUBSCRIPTION, including ALTER SUBSCRIPTION .. SKIP,
now require only that the role performing the operation own the
subscription, or inherit the privileges of the owner. However, to
use ALTER SUBSCRIPTION ... RENAME or ALTER SUBSCRIPTION ... OWNER TO,
you also need CREATE permission on the database. This is similar to
what we do for schemas. To change the owner of a schema, you must also
have permission to SET ROLE to the new owner, similar to what we do
for other object types.

Non-superusers are required to specify a password for authentication
and the remote side must use the password, similar to what is required
for postgres_fdw and dblink.  A superuser who wants a non-superuser to
own a subscription that does not rely on password authentication may
set the new password_required=false property on that subscription. A
non-superuser may not set password_required=false and may not modify a
subscription that already has password_required=false.

This new password_required subscription property works much like the
eponymous postgres_fdw property.  In both cases, the actual semantics
are that a password is not required if either (1) the property is set
to false or (2) the relevant user is the superuser.

Patch by me, reviewed by Andres Freund, Jeff Davis, Mark Dilger,
and Stephen Frost (but some of those people did not fully endorse
all of the decisions that the patch makes).

Discussion: http://postgr.es/m/CA+TgmoaDH=0Xj7OBiQnsHTKcF2c4L+=gzPBUKSJLh8zed2_+Dg@mail.gmail.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This role can be granted to non-superusers to allow them to issue
CREATE SUBSCRIPTION. The non-superuser must additionally have CREATE
permissions on the database in which the subscription is to be
created.

Most forms of ALTER SUBSCRIPTION, including ALTER SUBSCRIPTION .. SKIP,
now require only that the role performing the operation own the
subscription, or inherit the privileges of the owner. However, to
use ALTER SUBSCRIPTION ... RENAME or ALTER SUBSCRIPTION ... OWNER TO,
you also need CREATE permission on the database. This is similar to
what we do for schemas. To change the owner of a schema, you must also
have permission to SET ROLE to the new owner, similar to what we do
for other object types.

Non-superusers are required to specify a password for authentication
and the remote side must use the password, similar to what is required
for postgres_fdw and dblink.  A superuser who wants a non-superuser to
own a subscription that does not rely on password authentication may
set the new password_required=false property on that subscription. A
non-superuser may not set password_required=false and may not modify a
subscription that already has password_required=false.

This new password_required subscription property works much like the
eponymous postgres_fdw property.  In both cases, the actual semantics
are that a password is not required if either (1) the property is set
to false or (2) the relevant user is the superuser.

Patch by me, reviewed by Andres Freund, Jeff Davis, Mark Dilger,
and Stephen Frost (but some of those people did not fully endorse
all of the decisions that the patch makes).

Discussion: http://postgr.es/m/CA+TgmoaDH=0Xj7OBiQnsHTKcF2c4L+=gzPBUKSJLh8zed2_+Dg@mail.gmail.com
</pre>
</div>
</content>
</entry>
<entry>
<title>Add macros for ReorderBufferTXN toptxn.</title>
<updated>2023-03-17T02:59:41+00:00</updated>
<author>
<name>Amit Kapila</name>
<email>akapila@postgresql.org</email>
</author>
<published>2023-03-17T02:59:41+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=e709596b25bd184d6566dfff240e3f672a548afe'/>
<id>e709596b25bd184d6566dfff240e3f672a548afe</id>
<content type='text'>
Currently, there are quite a few places in reorderbuffer.c that tries to
access top-transaction for a subtransaction. This makes the code to access
top-transaction consistent and easier to follow.

Author: Peter Smith
Reviewed-by: Vignesh C, Sawada Masahiko
Discussion: https://postgr.es/m/CAHut+PuCznOyTqBQwjRUu-ibG-=KHyCv-0FTcWQtZUdR88umfg@mail.gmail.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, there are quite a few places in reorderbuffer.c that tries to
access top-transaction for a subtransaction. This makes the code to access
top-transaction consistent and easier to follow.

Author: Peter Smith
Reviewed-by: Vignesh C, Sawada Masahiko
Discussion: https://postgr.es/m/CAHut+PuCznOyTqBQwjRUu-ibG-=KHyCv-0FTcWQtZUdR88umfg@mail.gmail.com
</pre>
</div>
</content>
</entry>
<entry>
<title>Allow the use of indexes other than PK and REPLICA IDENTITY on the subscriber.</title>
<updated>2023-03-15T03:19:04+00:00</updated>
<author>
<name>Amit Kapila</name>
<email>akapila@postgresql.org</email>
</author>
<published>2023-03-15T03:06:38+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=89e46da5e511a6970e26a020f265c9fb4b72b1d2'/>
<id>89e46da5e511a6970e26a020f265c9fb4b72b1d2</id>
<content type='text'>
Using REPLICA IDENTITY FULL on the publisher can lead to a full table scan
per tuple change on the subscription when REPLICA IDENTITY or PK index is
not available. This makes REPLICA IDENTITY FULL impractical to use apart
from some small number of use cases.

This patch allows using indexes other than PRIMARY KEY or REPLICA
IDENTITY on the subscriber during apply of update/delete. The index that
can be used must be a btree index, not a partial index, and it must have
at least one column reference (i.e. cannot consist of only expressions).
We can uplift these restrictions in the future. There is no smart
mechanism to pick the index. If there is more than one index that
satisfies these requirements, we just pick the first one. We discussed
using some of the optimizer's low-level APIs for this but ruled it out
as that can be a maintenance burden in the long run.

This patch improves the performance in the vast majority of cases and the
improvement is proportional to the amount of data in the table. However,
there could be some regression in a small number of cases where the indexes
have a lot of duplicate and dead rows. It was discussed that those are
mostly impractical cases but we can provide a table or subscription level
option to disable this feature if required.

Author: Onder Kalaci, Amit Kapila
Reviewed-by: Peter Smith, Shi yu, Hou Zhijie, Vignesh C, Kuroda Hayato, Amit Kapila
Discussion: https://postgr.es/m/CACawEhVLqmAAyPXdHEPv1ssU2c=dqOniiGz7G73HfyS7+nGV4w@mail.gmail.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Using REPLICA IDENTITY FULL on the publisher can lead to a full table scan
per tuple change on the subscription when REPLICA IDENTITY or PK index is
not available. This makes REPLICA IDENTITY FULL impractical to use apart
from some small number of use cases.

This patch allows using indexes other than PRIMARY KEY or REPLICA
IDENTITY on the subscriber during apply of update/delete. The index that
can be used must be a btree index, not a partial index, and it must have
at least one column reference (i.e. cannot consist of only expressions).
We can uplift these restrictions in the future. There is no smart
mechanism to pick the index. If there is more than one index that
satisfies these requirements, we just pick the first one. We discussed
using some of the optimizer's low-level APIs for this but ruled it out
as that can be a maintenance burden in the long run.

This patch improves the performance in the vast majority of cases and the
improvement is proportional to the amount of data in the table. However,
there could be some regression in a small number of cases where the indexes
have a lot of duplicate and dead rows. It was discussed that those are
mostly impractical cases but we can provide a table or subscription level
option to disable this feature if required.

Author: Onder Kalaci, Amit Kapila
Reviewed-by: Peter Smith, Shi yu, Hou Zhijie, Vignesh C, Kuroda Hayato, Amit Kapila
Discussion: https://postgr.es/m/CACawEhVLqmAAyPXdHEPv1ssU2c=dqOniiGz7G73HfyS7+nGV4w@mail.gmail.com
</pre>
</div>
</content>
</entry>
</feed>
