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
