Re: BUG #17695: Failed Assert in logical replication snapbuild.
От | Daniel Gustafsson |
---|---|
Тема | Re: BUG #17695: Failed Assert in logical replication snapbuild. |
Дата | |
Msg-id | 9C8BF118-5869-49B0-81D7-BA072AD8E88E@yesql.se обсуждение исходный текст |
Ответ на | Re: BUG #17695: Failed Assert in logical replication snapbuild. (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: BUG #17695: Failed Assert in logical replication snapbuild.
Re: BUG #17695: Failed Assert in logical replication snapbuild. |
Список | pgsql-bugs |
> On 23 May 2023, at 13:00, Alexander Lakhin <exclusion@gmail.com> wrote: > > 22.05.2023 03:56, Masahiko Sawada wrote: >> On Thu, May 18, 2023 at 11:00 PM Alexander Lakhin <exclusion@gmail.com> wrote: >> >>> I can easily (without gdb and sleep()) reproduce the issue on master with >>> the following script: >>> ... >> Thank you for sharing the script. But it seems not stable as I could >> not reproduce the issue in my environment. I think we need a stable >> reproducer so that we can include it in core regression tests. Or it >> may be okay not to include it if we could not find a convenient way >> and the fix is trivial. > > I've came to the minimal reproducer: Thanks for the reproducer, I was able to reproduce this in HEAD and v16. > It's hardly suitable for the regression test, but it clearly demonstrates the > issue without using gdb. With the fix from [1] applied, I've got no failures, > even with numclients=100, for 10 runs. > > I also think, that the fix is simple enough to be committed without a > complicated/resource-intensive regression test. I'm not convinced we need a regression test for this as it would be very expensive and potentially brittle for older/slower buildfarm members while giving few gains. I've applied this to HEAD and backpatched it to v16. -- Daniel Gustafsson
В списке pgsql-bugs по дате отправления: