Re: BUG #17695: Failed Assert in logical replication snapbuild.
От | Masahiko Sawada |
---|---|
Тема | Re: BUG #17695: Failed Assert in logical replication snapbuild. |
Дата | |
Msg-id | CAD21AoBnerkzqkSuES7r=cFdDd5Mpk-kjXoMibtqtfDL9XU6jQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17695: Failed Assert in logical replication snapbuild. (Daniel Gustafsson <daniel@yesql.se>) |
Список | pgsql-bugs |
On Wed, Jul 5, 2023 at 12:43 AM Daniel Gustafsson <daniel@yesql.se> wrote: > > > 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. Thanks! Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-bugs по дате отправления: