Re: AW: AW: AW: AW: Replication Testing- How to introduce a Lag
| От | Laurenz Albe |
|---|---|
| Тема | Re: AW: AW: AW: AW: Replication Testing- How to introduce a Lag |
| Дата | |
| Msg-id | 89d63402747edb3bf80ff668fdd63cc77334f446.camel@cybertec.at обсуждение исходный текст |
| Ответ на | AW: AW: AW: AW: Replication Testing- How to introduce a Lag ("Subramanian,Ramachandran" <ramachandran.subramanian@alte-leipziger.de>) |
| Ответы |
AW: AW: AW: AW: AW: Replication Testing- How to introduce a Lag
|
| Список | pgsql-novice |
On Mon, 2026-03-23 at 16:36 +0000, Subramanian,Ramachandran wrote: > I noticed that RBAs are not incremented one for one . i.e 1 row inserted does not mean RBA=RBA+1 . 1 row updated doesnot mean RBA=RBA+1 > > I have ALTER SYSTEM SET recovery_min_apply_delay=300000 ; ( on the stand by side ) > > On the Source side > A simple create table results in a RBA difference of 108328 > > A simple insert of 1 row results in a RBA difference of 296 sometimes 96 > > Is there a way to estimate roughly the amount of data that remains to be transfered ? I don't know what an RBA is... If you are using recovery_min_apply_delay, don't measure the replication lag with regard to the replay_lsn, because replay is deliberately delayed. Instead, measure the difference to flush_lsn, the WAL position successfully transferred to the standby and persisted there. Yours, Laurenz Albe
В списке pgsql-novice по дате отправления: