4

A logical slot will emit each change just once in normal operation. The current position of each slot is persisted only at checkpoint, so in the case of a crash the slot may return to an earlier LSN, which will then cause recent changes to be resent when the server restarts. Logical decoding clients are responsible for avoiding ill effects from handling the same message more than once. Clients may wish to record the last LSN they saw when decoding and skip over any repeated data or (when using the replication protocol) request that decoding start from that LSN rather than letting the server determine the start point

Quoted from here

I'm implementing a logical (streaming) replication.

Thus far things are looking good but I'm unable to understand why restart_lsn entry is not changed.

i.e I do this..

SELECT * FROM pg_replication_slots;
 slot_name |  plugin  | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn
-----------+----------+-----------+--------+----------+--------+------------+------+--------------+-------------
 pgx_test  | wal2json | logical   |  12641 | postgres | t      |      16045 |      |      8544916 | 2/B1BC5330 

Insert 2/3 record

SELECT * FROM pg_stat_replication;
  pid  | usesysid |     usename     | application_name | client_addr | client_hostname | client_port |          backend_start           | backend_xmin |   state   | sent_location | write_location | flush_location | replay_location | sync_priority | sync_state
-------+----------+-----------------+------------------+-------------+-----------------+-------------+----------------------------------+--------------+-----------+---------------+----------------+----------------+-----------------+---------------+------------
 16315 |  1601109 | pgx_replication |                  | 127.0.0.1   |                 |       50112 | 2019-03-11 17:33:18.150179+05:30 |              | streaming | 2/B1BCA0F8    |                |                |                 |             0 | async

The sent_location gets updated but not the restart_lsn, even though I ran a checkpoint command had set the checkoint_timeout=1m but still the replay_lsn does not change.

SELECT * FROM pg_replication_slots;
 slot_name |  plugin  | slot_type | datoid | database | active | active_pid | xmin | catalog_xmin | restart_lsn
-----------+----------+-----------+--------+----------+--------+------------+------+--------------+-------------
 pgx_test  | wal2json | logical   |  12641 | postgres | t      |      16315 |      |      8544916 | 2/B1BC5330
(1 row)

Any reason why this happens?

1 Answer 1

0

first we need to understand what exactly restart_lsn is...

restart_lsn:- The address (LSN) of oldest WAL which still might be required by the consumer of this slot and thus won't be automatically removed during checkpoints.

It is the definition from official postgres documentation.

or we can say that restart_lsn is the oldest LSN from which server must retain WAL changes,even after check point process because to facilitate logical decoding after server is restarted.

When publisher's server stops due to powerloss/something, after restarting the publisher server...output plugin try to decode changes from restart_lsn point in WAL so that transactions which are not yet committed at the time when server stopped are decoded from restart_lsn...so that logical replication process is not stopped....so restart_lsn helps to continue logical decoding without fail.

In your case when you try to insert many rows you will find restart_lsn will change after sometime....to new value

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.