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+hUKGJBxaBgBfG4tHzXNFyTX9hQ6aU0OCfTmvNs2TU7VZWLXg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: |
Список | pgsql-hackers |
On Fri, Feb 11, 2022 at 7:50 AM Robert Haas <robertmhaas@gmail.com> wrote: > The main question in my mind is who is going to actually make that > happen. It was your idea (I think), Thomas coded it, and my commit > made it a live problem. So who's going to get something committed > here? I was about to commit that, because the original Windows problem it solved is showing up occasionally in CI failures (that is, it already solves a live problem, albeit a different and non-data-corrupting one): https://www.postgresql.org/message-id/CA%2BhUKGJp-m8uAD_wS7%2BdkTgif013SNBSoJujWxvRUzZ1nkoUyA%40mail.gmail.com It seems like I should go ahead and do that today, and we can study further uses for PROCSIGNAL_BARRIER_SMGRRELEASE in follow-on work?
В списке pgsql-hackers по дате отправления: