Re: How to simulate sync/async standbys being closer/farther (network distance) to primary in core postgres?
От | Ashutosh Bapat |
---|---|
Тема | Re: How to simulate sync/async standbys being closer/farther (network distance) to primary in core postgres? |
Дата | |
Msg-id | CAExHW5vCgYNnBzmMrMy_TFQxRrRpf7u2gP4ONiZOoWzCe6q3Kw@mail.gmail.com обсуждение исходный текст |
Ответ на | How to simulate sync/async standbys being closer/farther (network distance) to primary in core postgres? (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: How to simulate sync/async standbys being closer/farther (network distance) to primary in core postgres?
|
Список | pgsql-hackers |
On Tue, Apr 5, 2022 at 9:23 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > > Hi, > > I'm thinking if there's a way in core postgres to achieve $subject. In > reality, the sync/async standbys can either be closer/farther (which > means sync/async standbys can receive WAL at different times) to > primary, especially in cloud HA environments with primary in one > Availability Zone(AZ)/Region and standbys in different AZs/Regions. > $subject may not be possible on dev systems (say, for testing some HA > features) unless we can inject a delay in WAL senders before sending > WAL. > > How about having two developer-only GUCs {async, > sync}_wal_sender_delay? When set, the async and sync WAL senders will > delay sending WAL by {async, sync}_wal_sender_delay > milliseconds/seconds? Although, I can't think of any immediate use, it > will be useful someday IMO, say for features like [1], if it gets in. > With this set of GUCs, one can even add core regression tests for HA > features. > > Thoughts? I think this is a common problem, people run into. Once way to simulate network delay is what you suggest, yes. But I was wondering if there are tools/libraries that can help us to do that. Googling gives OS specific tools but nothing like a C or perl library which can be used for this purpose. -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: