Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5
От | Masahiko Sawada |
---|---|
Тема | Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 |
Дата | |
Msg-id | CAD21AoCR5ULReGxM9VNsp91MamPYLNLM7oiWqizpb-gPSpicVg@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>) |
Ответы |
Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5
RE: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5 |
Список | pgsql-bugs |
On Wed, Jun 4, 2025 at 11:36 PM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > > Dear Sawada-san, > > > Alternative idea is to lower the constant value when using an > > assertion build. That way, we don't need to rely on injection points > > being enabled. > > Hmm, possible but I prefer current one. Two concerns: > > 1. > USE_ASSERT_CHECKING has not been used to change the value yet. The main usage is > to call debug functions in debug build. I think we have a similar precedent such as MT_NRELS_HASH to improve the test coverages. > 2. > If we add tests which is usable only for debug build, it must be run only when it > is enabled. IIUC such test does not exist yet. I think we need to test cases not to check if we reach a specific code point but to check if we can get the correct results even if we've executed various code paths. As for this bug, it is better to check that it works properly in a variety of cases. That way, we can check overflow cases and non-overflow cases also in test cases added in the future, improving the test coverage more. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-bugs по дате отправления: