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

From: SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, 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-30 07:06:31
Message-ID: CAHg+QDdeHo6ydZBs+T55fD8YYAHA8TOyRvK+c8EYSC9-wMjWXw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 29, 2021 at 10:38 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:

> On Thu, Dec 30, 2021 at 1:09 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
>> Hi,
>>
>> On 2021-12-29 11:34:53 -0800, SATYANARAYANA NARLAPURAM wrote:
>> > On Wed, Dec 29, 2021 at 11:31 AM Andres Freund <andres(at)anarazel(dot)de>
>> wrote:
>> > Andres, thanks for the comments. Agreed on this based on the previous
>> > discussions on this thread. Could you please share your thoughts on
>> adding
>> > it after SyncRepWaitForLSN()?
>>
>> I don't think that's good either - you're delaying transaction commit
>> (i.e. xact becoming visible / locks being released).
>
>
> Agree with that.
>
>
>> That also has the danger
>> of increasing lock contention (albeit more likely to be heavyweight locks
>> /
>> serializable state). It'd have to be after the transaction actually
>> committed.
>>
>
> Yeah, I think that would make sense, even though we will be allowing a new
> backend to get connected insert WAL, and get committed but after that, it
> will be throttled. However, if the number of max connections will be very
> high then even after we detected a lag there a significant amount WAL could
> be generated, even if we keep long-running transactions aside. But I think
> still it will serve the purpose of what Satya is trying to achieve.
>

I am afraid there are problems with making the RPO check post releasing the
locks. By this time the transaction is committed and visible to the other
backends (ProcArrayEndTransaction is already called) though the intention
is to block committing transactions that violate the defined RPO. Even
though we block existing connections starting a new transaction, it is
possible to do writes by opening a new connection / canceling the query. I
am not too much worried about the lock contention as the system is already
hosed because of the policy. This behavior is very similar to what
happens when the Sync standby is not responding. Thoughts?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2021-12-30 07:44:51 Re: Per-table storage parameters for TableAM/IndexAM extensions
Previous Message houzj.fnst@fujitsu.com 2021-12-30 06:45:30 RE: Confused comment about drop replica identity index