Re: Back-patch of: avoid multiple hard links to same WAL file after a crash
От | Noah Misch |
---|---|
Тема | Re: Back-patch of: avoid multiple hard links to same WAL file after a crash |
Дата | |
Msg-id | 20250311205749.a8.nmisch@google.com обсуждение исходный текст |
Ответ на | Re: Back-patch of: avoid multiple hard links to same WAL file after a crash (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Back-patch of: avoid multiple hard links to same WAL file after a crash
|
Список | pgsql-hackers |
On Mon, Mar 10, 2025 at 02:25:28PM +0900, Michael Paquier wrote: > On Thu, Mar 06, 2025 at 01:44:30PM -0600, Nathan Bossart wrote: > > On Thu, Mar 06, 2025 at 11:30:13AM -0800, Noah Misch wrote: > >> 1. Make v14 and v13 skip WAL recycling and preallocation during archive > >> recovery, like newer branches do. I think that means back-patching the six > >> commits cc2c7d6~4 cc2c7d6~3 cc2c7d6~2 cc2c7d6~1 cc2c7d6 e36cbef. > >> > >> 2. Revert 1f95181b44c843729caaa688f74babe9403b5850 and its v13 counterpart. > >> Avoid multiple hard links by making durable_rename_excl() first rename > >> oldfile to a temporary name. (I haven't thought this through in detail. > >> It may not suffice.) > >> > >> I'm leaning toward (1) at least enough to see how messy the back-patch would > >> be, since I don't like risks of designing old-branch-specific solutions when > >> v15/v16/v17 have a proven solution. What else should we be thinking about > >> before deciding? > > > > I agree with first attempting a back-patch. All of this stuff is from > > 2021-2022, so it's had time to bake and is IMHO lower risk. > Could it be possible for you to double-check and also run > more tests if your enviroments help? Thanks for crafting back-branch versions. I've queued a task to confirm I get the same result. There's a test case I'll polish, too.
В списке pgsql-hackers по дате отправления: