Re: avoid multiple hard links to same WAL file after a crash
От | Nathan Bossart |
---|---|
Тема | Re: avoid multiple hard links to same WAL file after a crash |
Дата | |
Msg-id | 20220705165838.GA1232533@nathanxps13 обсуждение исходный текст |
Ответ на | Re: avoid multiple hard links to same WAL file after a crash (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: avoid multiple hard links to same WAL file after a crash
|
Список | pgsql-hackers |
On Tue, Jul 05, 2022 at 10:19:49AM +0900, Michael Paquier wrote: > On Thu, May 05, 2022 at 08:10:02PM +0900, Michael Paquier wrote: >> I'd agree with removing all the callers at the end. pgrename() is >> quite robust on Windows, but I'd keep the two checks in >> writeTimeLineHistory(), as the logic around findNewestTimeLine() would >> consider a past TLI history file as in-use even if we have a crash >> just after the file got created in the same path by the same standby, >> and the WAL segment init part. Your patch does that. > > As v16 is now open for business, I have revisited this change and > applied 0001 to change all the callers (aka removal of the assertion > for the WAL receiver when it overwrites a TLI history file). The > commit log includes details about the reasoning of all the areas > changed, for clarity, as of the WAL recycling part, the TLI history > file part and basic_archive. Thanks! I wonder if we should add a comment in writeTimeLineHistoryFile() about possible concurrent use by a WAL receiver and the startup process and why that is okay. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: