Re: [PATCH] Atomic pgrename on Windows
От | David Steele |
---|---|
Тема | Re: [PATCH] Atomic pgrename on Windows |
Дата | |
Msg-id | e6a39222-56a2-cdfc-ae0c-56a1cd0b4193@pgmasters.net обсуждение исходный текст |
Ответ на | Re: [PATCH] Atomic pgrename on Windows (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Ответы |
Re: [PATCH] Atomic pgrename on Windows
|
Список | pgsql-hackers |
On 1/11/20 5:13 PM, Alexander Korotkov wrote: > On Tue, Jan 7, 2020 at 11:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > "If the link named by the new argument exists and the file's link > count becomes 0 when it is removed and no process has the file open, > the space occupied by the file shall be freed and the file shall no > longer be accessible. If one or more processes have the file open when > the last link is removed, the link shall be removed before rename() > returns, but the removal of the file contents shall be postponed until > all references to the file are closed." > > But issue is that on Windows POSIX rename() is kind of impossible to > implement. And I suspect other platforms may have issues too. > > Regarding "pg_stat_tmp/global.stat", which is a problem in particular > case, we may evade file renaming altogether. Instead, we may > implement shared-memory counter for filename. So, instead of > renaming, new reads will just come to new file. I tend to agree with Tom on the question of portability. But it seems upthread we have determined that this can't be sensibly isolated into a Windows-specific rename() function. Does anyone have any further ideas? If not I feel like this patch is going to need to be RWF again. Regards, -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: