Hi
On 15/10/18 23:11, pavan95 wrote:
> Hi Mark,
>
> Thanks for your response.
>
>> We'd probably need to see how you actually did your set up, and also how
>> you are deducing that there is a lag (e.g pg_stat_subscription)?
>
> *Setup*:
>
> *Publisher *:
>
> Out of n number of tables n-1 tables are opted for replication of DML
> changes.
>
> *Subscriber *:
>
> Subscription is created on the subscriber for the corresponding publication.
>
> *At times, I find(developer complains) about difference in records between
> some of the published tables.*
>
> For example, after successful configuration of replication, say it was
> configured successfully on Oct 1'st 2018 and verified that it is
> replicating. Then some n days in future, a developer complains a table named
> abc is not getting replicated(meaning the data inserted/updated/deleted for
> that table abc on publisher is not getting synced with subscriber).
>
> *Findings*:
>
> Here I found that for 1 of the published table the row count is not same on
> both publisher and subscriber:
>
> Publisher : select count(*) from table_A; No.of Rows= 3598
>
> Subscriber: select count(*) from table_A: No.of Rows= 3590
>
I suggest trying to make a self contained test case illustrating this
problem (maybe just a single table replicated). By that I mean an exact
sequence of commands (so we can try it too and see if you have found a bug)!
With respect to the question about wal files and LSN, see the function
pg_walfile_name(), e.g:
postgres=# SELECT pg_current_wal_lsn();
pg_current_wal_lsn
--------------------
0/51EB3BA8
(1 row)
postgres=# SELECT pg_walfile_name(pg_current_wal_lsn());
pg_walfile_name
--------------------------
000000010000000000000051
(1 row)
The other 2 questions will be more easily tackled when we know the exact
set of commands you are using to do set things up.
regards
Mark