Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tY8Ty-004NcI-Id for pgsql-general@arkaria.postgresql.org; Wed, 15 Jan 2025 18:51:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tY8Tx-00FauO-1S for pgsql-general@arkaria.postgresql.org; Wed, 15 Jan 2025 18:51:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tY8Tw-00FauD-KU for pgsql-general@lists.postgresql.org; Wed, 15 Jan 2025 18:51:13 +0000 Received: from mail-io1-xd31.google.com ([2607:f8b0:4864:20::d31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tY8Tu-000bHX-2l for pgsql-general@lists.postgresql.org; Wed, 15 Jan 2025 18:51:12 +0000 Received: by mail-io1-xd31.google.com with SMTP id ca18e2360f4ac-844e394395aso2542139f.3 for ; Wed, 15 Jan 2025 10:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736967069; x=1737571869; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=QXjlkWvg7YtwJrEr7fXBkJvWY7KnZF3Lprx9OTLE3YU=; b=lS/qZg2Y23c+VvHsWx+cLtcdRFNASor0QL/4UBJ1k9ihl4hNMEOR2pwve5KKMU5VN5 KqFw36Q/+Kuec2GNM5d4ZayPlNZQRxFCey/KXtjXV330yS8uEFSStk6Nqt+TxPtgQKUn Kx4y7N2DjQT1RbLdBeF/m5wAqDvS9MiS214Im6eAeZfoIfVx7GRmM9zfLboK4DlJX6oM QeVDRWKmkZQfKzyXPWgqG8vwrrkMi2N3umHm0cIU62vVLs1DLzuZJADVpIfHSTNLwYvr m7lR96kdPhscu2yuRF+OkCHl+8GiNL3YXKZEQVteYVlZbhyTQ35emRJODctpY+g3Himm QGDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736967069; x=1737571869; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QXjlkWvg7YtwJrEr7fXBkJvWY7KnZF3Lprx9OTLE3YU=; b=wHN4tOHG+4YtEmmBhBM5Mj7GlrOZqnTinticsyI+cq6Rw0KONjU8n185oVdZGb6iVG vkBD+q+Tjj/zCzts8BJIVflwGGmYf0bg/STpd/PUHJPkqeN5ryMIENTU43qLH4hAYT/f OcZIzGpvxD+rc9qOU3mioprFCUne9XT9W/nbsJrtXkAKv7LHKItibD4c6BThV4yq7FVe +quBY3gPXmOGbdF3i9K82cGe3NDM39hvah2WmO8Cp/18ZjPet2ntKbb/Pnb9feOtpAuf upmd8O7KOmWtIHditSZeTD3oDg/rhn8qi+NIj4TmKUXq4v7xG0R6y7ZBSdtD4yNKcaki acbw== X-Gm-Message-State: AOJu0YxlixrgvKjEBXrVyl9sstL69IMSTzwQMhg02goDhYMuDS7U/tCU Y6aBrTlFFzMOezsqQAdcvyWvbky1xSPBAjtV0/hTvANpCw0sLFpOf/6HDcfZqXsRP6L8XVuNxja L7uChMRqSUo6jrlO60EG2QKKpqmANER24 X-Gm-Gg: ASbGncs24RTzX2RJMIS4Szu8mt0AjkWIxovYpOwn67lQP1q5i2lUiJzxiYngcCw8SN+ jyepvmSXebYEvkC+kZMq6Hjy+ym0legA1iB6ysg== X-Google-Smtp-Source: AGHT+IHJ4znJflhTfTHBd76w6OMG38Q8JVM2WXVrtXrlujKfiXRisx2UAJs4fCHGcSho2VJx3+OPUXQgE235Mr1P9AE= X-Received: by 2002:a05:6e02:1988:b0:3ce:7c7d:37d6 with SMTP id e9e14a558f8ab-3ce7c7d39b5mr70481285ab.10.1736967069061; Wed, 15 Jan 2025 10:51:09 -0800 (PST) MIME-Version: 1.0 From: Tim Gerber Date: Wed, 15 Jan 2025 12:50:58 -0600 X-Gm-Features: AbW1kvYRui1t0ur5CZhHIjyWOp6ddL7nZwhWP0usFePrDE9A0WJ-T3PYjmF6v2w Message-ID: Subject: Data Out of Sync with Physical Streaming Replication To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000235b25062bc32979" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000235b25062bc32979 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, We have run into an issue where the data for a primary and standby Postgres instances are out of sync. We are using streaming physical replication. We have encountered this issue several times over the last year on different Postgres Clusters. Postgres indicates everything is in sync but we can clearly see that is not the case. The essentials: PG Verion: 14.7 OS: Rocky Linux 8.10 -> Linux 4.18.0-553.30.1.el8_10.x86_64 Server: VMWare VM Storage: Enterprise level SSD We are starting to push Postgres 17 but it will be a while before we upgrade our existing PG 14 DB=E2=80=99s, therefore, I need to figure out wh= y this occurs in PG 14. I plan on at a minimum, upgrading to PG 14.15. I have a cluster setup to show this. We are using the default asynchronous replication. The primary and standby are in the same data center. I haven=E2=80=99t been able to reproduce this on demand. Initially, I though= t it might be a storage issue, but we are not seeing any errors in dmesg, kernel log, journalctl, or on the storage controller. I=E2=80=99m hoping someone has seen something similar and has some guidance= on further troubleshooting this. On the PRIMARY, we can see the replication slot is running: -- DB is in read-write mode: postgres=3D# select pg_is_in_recovery(); pg_is_in_recovery ------------------- f -- We have single replication slot that shows the lsn written, sent, flushed, and replayed is all the same: postgres=3D# select * from pg_stat_replication; -[ RECORD 1 ]----+------------------------------ pid | 2457681 usesysid | 16384 usename | xxxxxxxxxx application_name | xxxxxxxxxxxxxxxx client_addr | yyy.yyy.yyy.yyy client_hostname | client_port | 58522 backend_start | 2025-01-15 11:03:26.99902-06 backend_xmin | state | streaming sent_lsn | 0/1E0001B8 write_lsn | 0/1E0001B8 flush_lsn | 0/1E0001B8 replay_lsn | 0/1E0001B8 write_lag | flush_lag | replay_lag | sync_priority | 0 sync_state | async reply_time | 2025-01-15 11:04:27.149521-06 -- Primary shows no database conflicts: postgres=3D# select * from pg_stat_database_conflicts; -[ RECORD 1 ]----+---------- datid | 1 datname | template1 confl_tablespace | 0 confl_lock | 0 confl_snapshot | 0 confl_bufferpin | 0 confl_deadlock | 0 -[ RECORD 2 ]----+---------- datid | 13747 datname | template0 confl_tablespace | 0 confl_lock | 0 confl_snapshot | 0 confl_bufferpin | 0 confl_deadlock | 0 -[ RECORD 3 ]----+---------- datid | 16390 datname | issuedb confl_tablespace | 0 confl_lock | 0 confl_snapshot | 0 confl_bufferpin | 0 confl_deadlock | 0 -[ RECORD 4 ]----+---------- datid | 13748 datname | postgres confl_tablespace | 0 confl_lock | 0 confl_snapshot | 0 confl_bufferpin | 0 confl_deadlock | 0 On the STANDBY server, we can see that there is no lag: -- Instance is in recovery mode: postgres=3D# select pg_is_in_recovery(); pg_is_in_recovery ------------------- t -- Received and replayed lsn are the same. Note, these also match the lsn from the primary. postgres=3D# select pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(); -[ RECORD 1 ]-----------+----------- pg_last_wal_receive_lsn | 0/1E0001B8 pg_last_wal_replay_lsn | 0/1E0001B8 -- no conflicts: postgres=3D# select * from pg_stat_database_conflicts; -[ RECORD 1 ]----+---------- datid | 1 datname | template1 confl_tablespace | 0 confl_lock | 0 confl_snapshot | 0 confl_bufferpin | 0 confl_deadlock | 0 -[ RECORD 2 ]----+---------- datid | 13747 datname | template0 confl_tablespace | 0 confl_lock | 0 confl_snapshot | 0 confl_bufferpin | 0 confl_deadlock | 0 -[ RECORD 3 ]----+---------- datid | 16390 datname | issuedb confl_tablespace | 0 confl_lock | 0 confl_snapshot | 0 confl_bufferpin | 0 confl_deadlock | 0 -[ RECORD 4 ]----+---------- datid | 13748 datname | postgres confl_tablespace | 0 confl_lock | 0 confl_snapshot | 0 confl_bufferpin | 0 confl_deadlock | 0 I've performed a switchover multiple times meaning the standby has become the primary and the primary has become the standby. Not all tables are out of sync. In this case, it is three of them: PRIMARY: issuedb=3D# select count(1) from issue; count ------- 2 (1 row) issuedb=3D# select count(1) from comment; count ------- 1 (1 row) issuedb=3D# select count(1) from troubleshoot_issue; count ------- 2 (1 row) STANDBY: issuedb=3D# select count(1) from issue; count ------- 3 (1 row) issuedb=3D# select count(1) from comment; count ------- 4 (1 row) issuedb=3D# select count(1) from troubleshoot_issue; count ------- 3 (1 row) Both are on timeline 21: PRIMARY: postgres=3D# SELECT timeline_id FROM pg_control_checkpoint(); timeline_id ------------- 21 STANDBY: postgres=3D# SELECT timeline_id FROM pg_control_checkpoint(); timeline_id ------------- 21 Archive mode is on. I ran pg_amcheck and everything came back clean. I know synchronous replication is an option, but it feels like something else is going on and would like to get to the bottom of it. Any ideas on what could be causing this? I=E2=80=99m planning on turning o= n data_checksums and running pg_checksums to see if any corruption is found. Thanks for the time. Best Regards, Tim --000000000000235b25062bc32979 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi All,

We have run into an issue where the data for a primary and standby Postgres instances are out of sync. We are using streaming physical replication.=C2=A0 We have encountered this issue several times over the last year on different Postgres Clusters.=C2= =A0 Postgres indicates everything is in sync but we can clearly see that is not the case.

=C2=A0

The essentials:

=C2=A0

PG Verion: 1= 4.7

OS: Rocky Linux 8.10=C2=A0 -> Linux 4.18.0-553.30.1.el8_10.x86_64

Server: VMWare = VM

Storage:=C2=A0 Enterprise level SSD

=C2=A0

We are starting to push P= ostgres 17 but it will be a while before we upgrade our existing PG 14 DB=E2=80=99s, therefore, I need to fig= ure out why this occurs in PG 14. I plan on at a minimum, upgrading to PG 14.15.=C2=A0 =

=C2=A0

I have a cluster setup to show this= . We are using the default asynchronous replication.=C2=A0=C2=A0 The primary and standby are in the same data center.=C2=A0=C2=A0 I haven=E2=80= =99t been able to reproduce this on demand.=C2=A0 Initially, I thought it might be a storage issue, but we are not seeing any errors in dmesg, kernel log, journalctl, or on the storage controller.=C2=A0

=C2=A0

I=E2=80=99m hoping someone has seen= something similar and has some guidance on further troubleshooting this.

=C2=A0

=C2=A0

On the PRIMARY, we can see the replication s= lot is running:



-- =C2=A0DB is in read-write mode:

=C2=A0

p= ostgres=3D# select pg_is_in_recovery();

=C2=A0pg_is_in_reco= very

-------------------

=C2=A0f

=C2=A0

=C2=A0

-- =C2=A0We have single replication slot that shows the lsn written, sent, flushed, and replayed is= all the same:

postgres=3D# select * from pg_stat_replication;

-[ RECORD 1 ]----+------------------------------

pid= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | 2457681

usesysid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | 16384

usename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | xxxxxxxxxx

application_name | xxxxxxxxxxxxxxxx<= /p>

client_addr=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | yyy.yyy.yyy.yyy

client_hostname=C2=A0 |

cli= ent_port=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 58522

backend_start=C2=A0=C2=A0=C2=A0 | 2025-01-15 11:03:26.99902-06

backend_xmin=C2=A0=C2=A0=C2=A0= =C2=A0 |

state=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | streaming

sent_lsn=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | 0/1E0001B8

write_lsn=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | 0/1E0001B8

flush_lsn=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | 0/1E0001B8

replay_lsn=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 0/1E0001B8

write_lag=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 |

flush_lag=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=

replay_lag=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

sync_priority=C2=A0=C2=A0=C2=A0 | 0

sync_state=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | async

reply_time=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 2025-01-15 11:04:27.149521-06

=C2=A0

=C2=A0=

=C2=A0

=C2=A0

=C2=A0

-- =C2=A0Primary shows no database conflicts:

=C2=A0

postgres=3D# se= lect * from=C2=A0 pg_stat_database_conflicts;

-[ RECORD 1 ]----+----------

datid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | 1

datname=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | template1

confl_tablespace | 0

confl_lock= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 0

confl_snapshot=C2= =A0=C2=A0 | 0

confl_bufferpin=C2=A0 | 0

con= fl_deadlock=C2=A0=C2=A0 | 0

-[ RECORD 2 ]----+----------

datid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | 13747

datname=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | template0

confl_tablespace | 0

confl_lock= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 0

confl_snapshot=C2= =A0=C2=A0 | 0

confl_bufferpin=C2=A0 | 0

con= fl_deadlock=C2=A0=C2=A0 | 0

-[ RECORD 3 ]----+----------

datid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | 16390

datname=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | issuedb

confl_tablespace | 0

confl_lock=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 0

confl_snapshot=C2=A0= =C2=A0 | 0

confl_bufferpin=C2=A0 | 0

confl_= deadlock=C2=A0=C2=A0 | 0

-[ RECORD 4 ]----+----------

datid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | 13748

datname=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | postgres

confl_tablespace | 0

confl_lock=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 0

confl_snapshot=C2=A0= =C2=A0 | 0

confl_bufferpin=C2=A0 | 0

confl_= deadlock=C2=A0=C2=A0 | 0

=C2=A0

=C2=A0

<= p class=3D"MsoNormal" style=3D"margin:0in;font-size:11pt;font-family:Aptos,= sans-serif">=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On the STANDBY server= , we can see that there is no lag:

=C2=A0

-= - =C2=A0Instance is in recovery mode:

postgres=3D# select pg_is_in_recovery();

=

=C2=A0pg_is_in_recovery

-------------------

=C2=A0t

=C2=A0

=C2=A0

-- =C2=A0Received and replayed lsn are the same. Note, these also match the lsn from the primary.=

=C2=A0

postgres=3D# select pg_last_wal_rec= eive_lsn(), pg_last_wal_replay_lsn();

-[ RECORD 1 ]-----------+--------= ---

pg_last_wal_receive_lsn | 0/1E0001B8

pg= _last_wal_replay_lsn=C2=A0 | 0/1E0001B8

=C2=A0

=C2=A0

= =C2=A0

=C2=A0

-- =C2=A0=C2=A0no conflicts:<= /p>

=C2=A0

postgres=3D# select * from=C2=A0 pg_stat_database_conflicts;

-[ RECORD 1 ]----+----------

datid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | 1

datname=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | template1

confl_tablespace | 0

confl_lock= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 0

confl_snapshot=C2= =A0=C2=A0 | 0

confl_bufferpin=C2=A0 | 0

con= fl_deadlock=C2=A0=C2=A0 | 0

-[ RECORD 2 ]----+----------

datid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | 13747

datname=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | template0

confl_tablespace | 0

confl_lock= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 0

confl_snapshot=C2= =A0=C2=A0 | 0

confl_bufferpin=C2=A0 | 0

con= fl_deadlock=C2=A0=C2=A0 | 0

-[ RECORD 3 ]----+----------

datid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | 16390

datname=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | issuedb

confl_tablespace | 0

confl_lock=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 0

confl_snapshot=C2=A0= =C2=A0 | 0

confl_bufferpin=C2=A0 | 0

confl_= deadlock=C2=A0=C2=A0 | 0

-[ RECORD 4 ]----+----------

datid=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | 13748

datname=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | postgres

confl_tablespace | 0

confl_lock=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 0

confl_snapshot=C2=A0= =C2=A0 | 0

confl_bufferpin=C2=A0 | 0

confl_= deadlock=C2=A0=C2=A0 | 0

=C2=A0

=C2=A0

<= p class=3D"MsoNormal" style=3D"margin:0in;font-size:11pt;font-family:Aptos,= sans-serif">=C2=A0

=C2=A0

=C2=A0

I've performed a switchover multiple times meaning the standby has become the primary and the primary has become the standby.=C2= =A0

Not all tables are out of sync.=C2=A0 In this case, it= is three of them:

=C2=A0

=C2=A0

PRIMARY:

=C2=A0

issuedb=3D# select = count(1) from issue;

=C2=A0count

-------

=C2=A0=C2=A0=C2=A0=C2=A0 2

(1 row)

=C2=A0

=C2=A0

issuedb=3D# select coun= t(1) from comment;

=C2=A0count

-------

<= p class=3D"MsoNormal" style=3D"margin:0in;font-size:11pt;font-family:Aptos,= sans-serif">=C2=A0=C2=A0=C2=A0=C2=A0 1

(1 row)

=C2=A0

issuedb=3D# select count(1) from troubleshoot_i= ssue;

=C2=A0count

-------

= =C2=A0=C2=A0=C2=A0=C2=A0 2

(1 row)

=C2=A0

=C2=A0

STANDBY:

=C2=A0

issuedb=3D# select count(1) from issue;

=C2=A0co= unt

-------

=C2=A0=C2=A0=C2=A0=C2=A0 3

<= p class=3D"MsoNormal" style=3D"margin:0in;font-size:11pt;font-family:Aptos,= sans-serif">(1 row)

=C2=A0

=C2=A0

issuedb=3D# select count(1) from comment;

=C2=A0cou= nt

-------

=C2=A0=C2=A0=C2=A0=C2=A0 4

(1 row)

=C2=A0

issuedb=3D# sel= ect count(1) from troubleshoot_issue;

=C2=A0count

-------

=C2=A0=C2=A0=C2=A0=C2=A0 3

(= 1 row)

=C2=A0

=C2=A0

=C2=A0=

Both are on timeline 21:

=C2=A0

PRIMARY:

=C2=A0

postgres=3D# SELECT= timeline_id FROM pg_control_checkpoint();

=C2=A0timeline_= id

-------------

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 21

=C2=A0

= =C2=A0

=C2=A0

STANDBY:

=C2= =A0

postgres=3D# SELECT timeline_id FROM pg_control_checkpo= int();

=C2=A0timeline_id

-------------

<= p class=3D"MsoNormal" style=3D"margin:0in;font-size:11pt;font-family:Aptos,= sans-serif">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 21

=C2=A0

=C2=A0

Archive mode is on= .=C2=A0=C2=A0 I ran pg_amcheck and everything came back clean. I know synchronous replicati= on is an option, but it feels like something else is going on and would like to get to the bottom of it.

Any ideas on what could be causing this?=C2=A0 I=E2=80=99m= planning on turning on data_checksums and running pg_checksums to see if any corruption is found.

= =C2=A0

Thanks for the time.

=C2=A0

Best Regards,

Tim=C2=A0

--000000000000235b25062bc32979--