Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>
Cc: 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:25:06
Message-ID: CAFiTN-ufohibu=h1nY-hoA7YRV3qgerx=oBt41_r1xMSV+x1dg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 26, 2021 at 10:36 AM SATYANARAYANA NARLAPURAM <
satyanarlapuram(at)gmail(dot)com> wrote:

>
>> Actually all the WAL insertions are done under a critical section (except
>> few exceptions), that means if you see all the references of XLogInsert(),
>> it is always called under the critical section and that is my main worry
>> about hooking at XLogInsert level.
>>
>
> 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.
>
>
Yet another problem is that if we are in XlogInsert() that means we are
holding the buffer locks on all the pages we have modified, so if we add a
hook at that level which can make it wait then we would also block any of
the read operations needed to read from those buffers. I haven't thought
what could be better way to do this but this is certainly not good.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joel Jacobson 2021-12-26 06:46:41 Re: Foreign key joins revisited
Previous Message Julien Rouhaud 2021-12-26 05:23:31 Re: Throttling WAL inserts when the standby falls behind more than the configured replica_lag_in_bytes