Re: Replication Testing- How to introduce a Lag
| От | Laurenz Albe |
|---|---|
| Тема | Re: Replication Testing- How to introduce a Lag |
| Дата | |
| Msg-id | 013104103e016e84d59c1e2accb0b1b1f99d9870.camel@cybertec.at обсуждение |
| Ответ на | AW: AW: AW: AW: AW: Replication Testing- How to introduce a Lag ("Subramanian,Ramachandran" <ramachandran.subramanian@alte-leipziger.de>) |
| Ответы |
AW: Replication Testing- How to introduce a Lag
|
| Список | pgsql-novice |
On Tue, 2026-03-24 at 06:14 +0000, Subramanian,Ramachandran wrote: > I noticed that if I insert one row in a table at the source, the difference in LSNs > is not 1 . ( with a delibrately introduced delay on the apply side ), > > It is sometimes 96, sometimes 296 ( for the same table two inserts ) . Right, because the LSN is not a counter that increases with each new WAL record. It is a position in the WAL stream. The difference between the LSNs of two adjacent WAL records is not 1, but the byte count of the first WAL record. For example: if you insert a larger row, the LSN will advance more. Note also that not all inserts will produce the same kind of WAL: one insert might write a full page image to the WAL, while the next a normal insert record. > Is there a method to calculate the APPROXIMATE amount of data in ( Bytes ) > that are yet to be transfered from Source to Standby ? That's exactly what pg_wal_lsn_diff() does. What is your worry? What is your ultimate goal? Yours, Laurenz Albe
В списке pgsql-novice по дате отправления: