On Mon, 18 Oct 2021 at 12:17, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Japin Li <japi...@hotmail.com> writes:
>> On Mon, 18 Oct 2021 at 11:59, Michael Paquier <mich...@paquier.xyz> wrote:
>>> dblink.c has something similar as of applyRemoteGucs(), except that it
>>> does not do extra_float_digits. It would be nice to avoid more
>>> duplication for those things, at least on HEAD. On the top of my
>>> head, don't we have something similar for parallel workers when
>>> passing down GUCs from the leader?
>
>> Since it will be used in more than one places. IMO, we can implement it in
>> core.
>> Any thoughts?
>
> It's not going to be the same code everywhere. A logrep sender won't
> have a need to save-and-restore the settings like postgres_fdw does,
Thanks for your explanation. Yeah, we do not need reset the settings in
logical replication.
> AFAICS. Also, now that I look at it, dblink is doing the opposite
> thing of absorbing the sender's values.
>
Sorry I misunderstand. You are right, the dblink applies the remote
server's settings to local server.
Attached v3 patch modify the settings on sender as you suggest.
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
diff --git a/src/backend/postmaster/postmaster.c b/src/backend/postmaster/postmaster.c
index e2a76ba055..3c1b2fa85e 100644
--- a/src/backend/postmaster/postmaster.c
+++ b/src/backend/postmaster/postmaster.c
@@ -2223,6 +2223,20 @@ retry1:
{
am_walsender = true;
am_db_walsender = true;
+
+ /*
+ * Force assorted GUC parameters to settings that ensure
+ * that we'll output data values in a form that is
+ * unambiguous to the walreceiver.
+ */
+ port->guc_options = lappend(port->guc_options,
+ pstrdup("datestyle"));
+ port->guc_options = lappend(port->guc_options,
+ pstrdup("ISO"));
+ port->guc_options = lappend(port->guc_options,
+ pstrdup("intervalstyle"));
+ port->guc_options = lappend(port->guc_options,
+ pstrdup("postgres"));
}
else if (!parse_bool(valptr, &am_walsender))
ereport(FATAL,
diff --git a/src/test/subscription/t/100_bugs.pl b/src/test/subscription/t/100_bugs.pl
index baa4a90771..a88a61df41 100644
--- a/src/test/subscription/t/100_bugs.pl
+++ b/src/test/subscription/t/100_bugs.pl
@@ -6,7 +6,7 @@ use strict;
use warnings;
use PostgresNode;
use TestLib;
-use Test::More tests => 5;
+use Test::More tests => 6;
# Bug #15114
@@ -224,3 +224,44 @@ $node_sub->safe_psql('postgres', "DROP TABLE tab1");
$node_pub->stop('fast');
$node_pub_sub->stop('fast');
$node_sub->stop('fast');
+
+# Verify different datestyle between publisher and subscriber.
+$node_publisher = PostgresNode->new('datestyle_publisher');
+$node_publisher->init(allows_streaming => 'logical');
+$node_publisher->append_conf('postgresql.conf',
+ "datestyle = 'SQL, MDY'");
+$node_publisher->start;
+
+$node_subscriber = PostgresNode->new('datestyle_subscriber');
+$node_subscriber->init(allows_streaming => 'logical');
+$node_subscriber->append_conf('postgresql.conf',
+ "datestyle = 'SQL, DMY'");
+$node_subscriber->start;
+
+$node_publisher->safe_psql('postgres',
+ "CREATE TABLE tab_rep(a date)");
+$node_publisher->safe_psql('postgres',
+ "INSERT INTO tab_rep VALUES ('07-18-2021'), ('05-15-2018')");
+
+$node_subscriber->safe_psql('postgres',
+ "CREATE TABLE tab_rep(a date)");
+
+# Setup logical replication
+my $node_publisher_connstr = $node_publisher->connstr . ' dbname=postgres';
+$node_publisher->safe_psql('postgres',
+ "CREATE PUBLICATION tab_pub FOR ALL TABLES");
+$node_subscriber->safe_psql('postgres',
+ "CREATE SUBSCRIPTION tab_sub CONNECTION '$node_publisher_connstr' PUBLICATION tab_pub");
+
+$node_publisher->wait_for_catchup('tab_sub');
+
+my $result = $node_subscriber->safe_psql('postgres',
+ "SELECT count(*) FROM tab_rep");
+is($result, qq(2), 'failed to replication date from different datestyle');
+
+# Clean up the tables on both publisher and subscriber as we don't need them
+$node_publisher->safe_psql('postgres', 'DROP TABLE tab_rep');
+$node_subscriber->safe_psql('postgres', 'DROP TABLE tab_rep');
+
+$node_publisher->stop('fast');
+$node_subscriber->stop('fast');
