From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes |
Date: | 2021-12-26 05:23:31 |
Message-ID: | CAOBaU_YWhw4pjvDR7qwE9b3C0wgT9EiVXEGBTzO3zEoe+MS5Lg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Dec 26, 2021 at 1:06 PM SATYANARAYANA NARLAPURAM
<satyanarlapuram(at)gmail(dot)com> wrote:
>
> Got it, understood the concern. But can we document the limitations of the hook and let the hook take care of it? I don't expect an error to be thrown here since we are not planning to allocate memory or make file system calls but instead look at the shared memory state and add delays when required.
It wouldn't work. You can't make any assumption about how long it
would take for the replication lag to resolve, so you may have to wait
for a very long time. It means that at the very least the sleep has
to be interruptible and therefore can raise an error. In general
there isn't much you can due in a critical section, so this approach
doesn't seem sensible to me.
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2021-12-26 05:25:06 | Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes |
Previous Message | SATYANARAYANA NARLAPURAM | 2021-12-26 05:06:26 | Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes |