Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
От | Robert Haas |
---|---|
Тема | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: |
Дата | |
Msg-id | CA+TgmoZpTt3RYeB3LgdhtD5J0MOnODoVUb3HYt8Tba6wAxNNgQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: (Thomas Munro <thomas.munro@gmail.com>) |
Список | pgsql-hackers |
On Thu, Feb 10, 2022 at 3:11 PM Thomas Munro <thomas.munro@gmail.com> wrote: > 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? A bird in the hand is worth two in the bush. Unless it's a vicious, hand-biting bird. In other words, if you think what you've got is better than what we have now and won't break anything worse than it is today, +1 for committing, and more improvements can come when we get enough round tuits. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: