Feedback-ID: i76984098:Fastmail
Message-ID: <aa3168eb-f529-4e4a-bcb7-e01140ef5b3f@aklaver.com>
Date: Thu, 23 Jan 2025 08:38:02 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Records count mismatch with logical replication
To: Durgamahesh Manne <maheshpostgres9@gmail.com>
Cc: pgsql-general <pgsql-general@lists.postgresql.org>
References: <CAJCZko+gYNGiixGcqKAhjhLhUZ3QQg2rGs6nH7ZUNwTtjYLfGw@mail.gmail.com>
 <e1bd37c2-9e2c-4914-b8be-bd75b633dfc1@aklaver.com>
 <CAJCZko+HhLFkiDLDPg3fscUEO4uWyEFT4_e6GBMeywnnwRC-rg@mail.gmail.com>
 <79b7d5dc-3a1d-4ef0-9a3d-055268dc7d09@aklaver.com>
 <CAJCZkoLZb5ON_T-YecS3-1sQjiGUVLdgKjS93thQyzZKiaWuFQ@mail.gmail.com>
 <3691ad0c-189c-4290-a434-e03cb6301cac@aklaver.com>
 <CAJCZkoJgAh_T_NJU5Jn3mzJJQE4LE-tDEjEyP37gKNR1X0cDWQ@mail.gmail.com>
 <44e3ca5d-fcbd-4f96-a6a6-09becff15cd7@aklaver.com>
 <CAJCZkoLatfwsQ-puesPfjrYtUmaAwokWQvqShoTGfJ56QzLfQw@mail.gmail.com>
Content-Language: en-US
From: Adrian Klaver <adrian.klaver@aklaver.com>
In-Reply-To: <CAJCZkoLatfwsQ-puesPfjrYtUmaAwokWQvqShoTGfJ56QzLfQw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/aa3168eb-f529-4e4a-bcb7-e01140ef5b3f%40aklaver.com>
Precedence: bulk

On 1/22/25 18:53, Durgamahesh Manne wrote:
> 
> 
> 

>  > But records count varies with difference of more than 10 thousand
> 
> Have you looked at the I/0 statistics between the Postgres instances?
> 
> Seems everything looks good with pg replication slots

Except the subscriber is lagging behind the publisher.

'... everything looks good' is an opinion not actual data.

> 
> Does this pg logical slot get changes function help to pull pending 
> changes to subscription that can be sync with publication server for 
> real time sync ?

Are you referring to this?:

https://www.postgresql.org/docs/current/warm-standby.html#SYNCHRONOUS-REPLICATION

Though I am not sure you want to do this as from above:

"When requesting synchronous replication, each commit of a write 
transaction will wait until confirmation is received that the commit has 
been written to the write-ahead log on disk of both the primary and 
standby server. The only possibility that data can be lost is if both 
the primary and the standby suffer crashes at the same time. This can 
provide a much higher level of durability, though only if the sysadmin 
is cautious about the placement and management of the two servers. 
Waiting for confirmation increases the user's confidence that the 
changes will not be lost in the event of server crashes but it also 
necessarily increases the response time for the requesting transaction. 
The minimum wait time is the round-trip time between primary and standby."

If you are not referring to above then you will need to explain further.

> 
> Regards,
> Durgamahesh
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com