Re: Hick ups in Postgresql Logical Replication - Mailing list pgsql-admin

From Mark Kirkwood
Subject Re: Hick ups in Postgresql Logical Replication
Date
Msg-id 0eccff47-a5d8-56d3-8474-610378ad96d0@catalyst.net.nz
Whole thread Raw
In response to Re: Hick ups in Postgresql Logical Replication  (pavan95 <pavan.postgresdba@gmail.com>)
List pgsql-admin
Hi again,


On 16/10/18 18:26, pavan95 wrote:
>
> Hi Mark,
>
> My question was like how to get all the LSN's that are available in a WAL
> segment. For example, take a segment named "000000010000000000000051".
>
> So in the above archive log segment, how to get all the LSN's of all txn's
> which belong to that segment ?
>
> *The idea for asking this is, I will get the remote_lsn on the subscriber
> which was successfully applied from the view "pg_replication_origin_status".
>
> Based on the LSN, I will check in which archive segment that particular LSN
> is present(as you said above).
>
> And will find all the later LSN's(later to remote_lsn).
>
> So I can say that these many transactions are yet to be applied to the
> target.*
>
>
Well I think you are going to have to do a bit of work here to determine 
when the file name changes (e.g my system):

bench=# SELECT pg_walfile_name('0/51EB3BAE');
      pg_walfile_name
--------------------------
  000000010000000000000051
(1 row)

bench=# SELECT pg_walfile_name('0/50000001');
      pg_walfile_name
--------------------------
  000000010000000000000050
(1 row)

However, I'm not sure you are chasing the right problem. It seems to me 
that you need to grapple with what is (possibly) wrong with the 
streaming wal protocol used by logical rep, not the wal file business.

Again, I recommend you provide a precise test case that shows the 
problem, we can surely help you then!

regards
Mark




pgsql-admin by date:

Previous
From: pavan95
Date:
Subject: Re: Hick ups in Postgresql Logical Replication
Next
From: Laurenz Albe
Date:
Subject: Re: effective_cache_size cfg