Re: Error "initial slot snapshot too large" in create replication slot

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Error "initial slot snapshot too large" in create replication slot
Date: 2022-01-31 07:04:52
Message-ID: CAFiTN-sPuKuxQhS9ERaUhbTc2R+YDn9q3n0TbmEO1OMXptj64w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jan 31, 2022 at 11:50 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> SnapBUildInitialSnapshot tries to store XIDS of both top and sub
> transactions into snapshot->xip array but the array is easily
> overflowed and CREATE_REPLICATOIN_SLOT command ends with an error.
>
> To fix this, this patch is doing the following things.
>
> - Use subxip array instead of xip array to allow us have larger array
> for xids. So the snapshot is marked as takenDuringRecovery, which
> is a kind of abuse but largely reduces the chance of getting
> "initial slot snapshot too large" error.
>
> - Still if subxip is overflowed, retry with excluding subtransactions
> then set suboverflowed. This causes XidInMVCCSnapshot (finally)
> scans over subxip array for targetted top-level xid.
>
> We could take another way: make a !takenDuringRecovery snapshot by
> using xip instead of subxip. It is cleaner but it has far larger
> chance of needing to retry.
>
> (renamed the patch since it represented a part of the patch)
>

Thanks for the updated version. I will look into it this week.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-01-31 07:11:48 Re: make MaxBackends available in _PG_init
Previous Message Peter Eisentraut 2022-01-31 06:54:01 Re: Add header support to text format and matching feature