Re: Hick ups in Postgresql Logical Replication

Поиск
Список
Период
Сортировка
От Mark Kirkwood
Тема Re: Hick ups in Postgresql Logical Replication
Дата
Msg-id 0eccff47-a5d8-56d3-8474-610378ad96d0@catalyst.net.nz
обсуждение исходный текст
Ответ на Re: Hick ups in Postgresql Logical Replication  (pavan95 <pavan.postgresdba@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: pavan95
Дата:
Сообщение: Re: Hick ups in Postgresql Logical Replication
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: effective_cache_size cfg