Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
От | Andres Freund |
---|---|
Тема | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: |
Дата | |
Msg-id | 20220210222659.fqhdfi4wdscfsvl4@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To:
|
Список | pgsql-hackers |
Hi, On 2022-02-11 09:10:38 +1300, Thomas Munro wrote: > 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): +1 > 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? Yes. I wonder whether we really should make the barriers be conditional on defined(WIN32) || defined(USE_ASSERT_CHECKING) as done in that patch, even leaving wraparound dangers aside. On !windows we still have the issues of the space for the dropped / moved files not being released if there are processes having them open. That can be a lot of space if there's long-lived connections in a cluster that doesn't fit into s_b (because processes will have random fds open for writing back dirty buffers). And we don't truncate the files before unlinking when done as part of a DROP DATABASE... But that's something we can fine-tune later as well... Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: