Re: conchuela timeouts since 2021-10-09 system upgrade
От | Thomas Munro |
---|---|
Тема | Re: conchuela timeouts since 2021-10-09 system upgrade |
Дата | |
Msg-id | CA+hUKGL0Wdp9PTtJA-9OE8-vrE=Y=pkiK9raHVNLKJszBguJCw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: conchuela timeouts since 2021-10-09 system upgrade (Noah Misch <noah@leadboat.com>) |
Список | pgsql-bugs |
On Sun, Nov 14, 2021 at 1:17 PM Noah Misch <noah@leadboat.com> wrote: > On Sat, Nov 13, 2021 at 11:47:43PM +0500, Andrey Borodin wrote: > > I've adapted 7f580aa to functionality of REL_11 using "\if 0 = :client_id" metacommand. > > I really do not like idea of supporting background_pgbench() in older branches without counterpart in newer branches. > > But so far I didn't come up with some clever mutex idea for REL_10. > > That's a reasonable sentiment, but removing background_pgbench() isn't going > to fix 017_shm.pl. I'm not enthusiastic about any fix that repairs > src/bin/pgbench without repairing 017_shm.pl. I'm okay with skipping affected > test files on dragonfly >= 6 if you decide to cease figuring out how to make > them pass like the others do. Hmm, so if "IPC::Run got stuck when it should have been reaping that zombie", what's it stuck in, I guess select() or waitpid()? Maybe there' s a kernel bug but it seems hard to believe that a Unix system would have bugs in such fundamental facilities and still be able to build itself and ship a release... Otherwise I guess Perl, or perl scripts, would need to be confusing fds or pids or something? But that's hard to believe on its own, too, given the lack of problems on other systems that are pretty similar. If Andrey can still reproduce this, it'd be interesting to see a gdb backtrace, and also "ps O wchan" or perhaps kill -INFO $pid, and lsof for the process (or according to old pages found with google, perhaps the equivalent tool is "fstat" on that system).
В списке pgsql-bugs по дате отправления: