Re: BUG #17695: Failed Assert in logical replication snapbuild.
От | Masahiko Sawada |
---|---|
Тема | Re: BUG #17695: Failed Assert in logical replication snapbuild. |
Дата | |
Msg-id | CAD21AoDyE91TroZQOtSyjq-k9KmUOHTfUe1mG7kFLDCLTHNH_A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17695: Failed Assert in logical replication snapbuild. (Alexander Lakhin <exclusion@gmail.com>) |
Ответы |
Re: BUG #17695: Failed Assert in logical replication snapbuild.
|
Список | pgsql-bugs |
On Thu, May 18, 2023 at 11:00 PM Alexander Lakhin <exclusion@gmail.com> wrote: > > Hello Sawada-san, > > 17.05.2023 08:34, Masahiko Sawada wrote: > > > > When it comes to the original issue, I already shared the reproducible > > steps[4] and I've confirmed again with the steps that the issue still > > happens on 14 or later and the patch . However I don't find a way to > > reproduce it without sleep/gdb attach. > > I can easily (without gdb and sleep()) reproduce the issue on master with > the following script: > numclients=10 > rm -rf contrib/test_decoding_* > for ((c=1;c<=numclients;c++)); do > cp -r contrib/test_decoding contrib/test_decoding_$c > done > > for ((c=1;c<=numclients;c++)); do > EXTRA_REGRESS_OPTS="--dbname=regress_$c" make -s installcheck-force -C contrib/test_decoding_$c USE_MODULE_DB=1 > >"installcheck-$c.log" 2>&1 & > done > wait 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. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
В списке pgsql-bugs по дате отправления: