Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
От | Thomas Munro |
---|---|
Тема | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: |
Дата | |
Msg-id | CA+hUKG+AUQAm3pm+WFQNCv2LU0w+v9z0iozicdYVn_wmfy6=Rg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Tue, May 10, 2022 at 1:07 AM Robert Haas <robertmhaas@gmail.com> wrote: > On Sun, May 8, 2022 at 7:30 PM Thomas Munro <thomas.munro@gmail.com> wrote: > > LOG: still waiting for pid 1651417 to accept ProcSignalBarrier > > STATEMENT: alter database mydb set tablespace ts1; > This is a very good idea. OK, I pushed this, after making the ereport call look a bit more like others that talk about backend PIDs. > > Another thought is that it might be nice to be able to test with a > > dummy PSB that doesn't actually do anything. You could use it to see > > how fast your system processes it, while doing various other things, > > and to find/debug problems in other code that fails to handle > > interrupts correctly. Here's an attempt at that. I guess it could go > > into a src/test/modules/something instead of core, but on the other > > hand the PSB itself has to be in core anyway, so maybe not. Thoughts? > > No documentation yet, just seeing if people think this is worth > > having... better names/ideas welcome. > > I did this at one point, but I wasn't convinced it was going to find > enough bugs to be worth committing. It's OK if you're convinced of > things that didn't convince me, though. I'll leave this here for now.
В списке pgsql-hackers по дате отправления: