Re: [PATCH] Atomic pgrename on Windows

Hi, On March 30, 2020 9:17:00 AM PDT, Tom Lane wrote: >So far as pg_stat_tmp is concerned, I think there is reasonable hope >that that problem is just going to go away in the near future. >I've not been paying attention to the shared-memory stats collector >thread so I'm not sure if that's anywhe

Re: [PATCH] Atomic pgrename on Windows

David Steele writes: > On 1/11/20 5:13 PM, Alexander Korotkov wrote: >> 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 wil

Re: [PATCH] Atomic pgrename on Windows

On 1/11/20 5:13 PM, Alexander Korotkov wrote: On Tue, Jan 7, 2020 at 11:04 PM Tom Lane 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 n

Re: [PATCH] Atomic pgrename on Windows

On Tue, Jan 7, 2020 at 11:04 PM Tom Lane wrote: > Alexander Korotkov writes: > > I'm not sure issue we faced is really about single platform. TBH, the > > assumptions we place to rename function is very strict. We assume > > rename works atomically on system crash. And we indirectly assume it

Re: [PATCH] Atomic pgrename on Windows

Alexander Korotkov writes: > I'm not sure issue we faced is really about single platform. TBH, the > assumptions we place to rename function is very strict. We assume > rename works atomically on system crash. And we indirectly assume it > can work concurrently as least with file readers. The

Re: [PATCH] Atomic pgrename on Windows

On Tue, Jan 7, 2020 at 9:40 PM Tom Lane wrote: > Alexander Korotkov writes: > > On Tue, Jan 7, 2020 at 7:16 PM Tomas Vondra > > wrote: > >> I don't have access to a Windows machine and my developer experience > >> with that platform is pretty much nil, but I think this patch makes > >> sense. It

Re: [PATCH] Atomic pgrename on Windows

Alexander Korotkov writes: > On Tue, Jan 7, 2020 at 7:16 PM Tomas Vondra > wrote: >> I don't have access to a Windows machine and my developer experience >> with that platform is pretty much nil, but I think this patch makes >> sense. It's not an ideal solution, but it's not clear such solution >

Re: [PATCH] Atomic pgrename on Windows

Hi! On Tue, Jan 7, 2020 at 7:16 PM Tomas Vondra wrote: > I don't have access to a Windows machine and my developer experience > with that platform is pretty much nil, but I think this patch makes > sense. It's not an ideal solution, but it's not clear such solution > exists, and an improvement is

Re: [PATCH] Atomic pgrename on Windows

On Tue, Aug 06, 2019 at 09:03:08PM +0300, Alexander Korotkov wrote: ... Unfortunately, it seems that none of such strategies would fit all the cases. Basically, we have two option for renaming a file. * MoveFileEx() – safest possible option, less likely loose files, but takes a lock on target

Re: [PATCH] Atomic pgrename on Windows

Hi! I'd like to resume the discussion on this subject. Sorry for so long delay. On Sat, Jan 20, 2018 at 6:13 PM Magnus Hagander wrote: > On Tue, Nov 28, 2017 at 2:47 AM, Michael Paquier > wrote: >> >> On Mon, Nov 27, 2017 at 3:28 PM, Alexander Korotkov >> wrote: >> > Attached patch atomic-pg

Re: [PATCH] Atomic pgrename on Windows

On Tue, Mar 6, 2018 at 5:11 PM, David Steele wrote: > On 3/6/18 9:06 AM, Alexander Korotkov wrote: > > > > On Tue, Mar 6, 2018 at 5:04 PM, David Steele > > wrote: > > > > On 1/20/18 10:13 AM, Magnus Hagander wrote: > > > > > > Unlinking it first seems dang

Re: [PATCH] Atomic pgrename on Windows

On 3/6/18 9:06 AM, Alexander Korotkov wrote: > > On Tue, Mar 6, 2018 at 5:04 PM, David Steele > wrote: > > On 1/20/18 10:13 AM, Magnus Hagander wrote: > > > > Unlinking it first seems dangerous, as pointed out by Andres. > > > > What about first tr

Re: Re: [PATCH] Atomic pgrename on Windows

Hi, David! On Tue, Mar 6, 2018 at 5:04 PM, David Steele wrote: > On 1/20/18 10:13 AM, Magnus Hagander wrote: > > > > On Tue, Nov 28, 2017 at 2:47 AM, Michael Paquier > > mailto:michael.paqu...@gmail.com>> wrote: > > > > On Mon, Nov 27, 2017 at 3:28 PM, Alexander Korotkov > > mailto:a.kor

Re: Re: [PATCH] Atomic pgrename on Windows

Hi Alexander, On 1/20/18 10:13 AM, Magnus Hagander wrote: > > On Tue, Nov 28, 2017 at 2:47 AM, Michael Paquier > mailto:michael.paqu...@gmail.com>> wrote: > > On Mon, Nov 27, 2017 at 3:28 PM, Alexander Korotkov > mailto:a.korot...@postgrespro.ru>> wrote: > > Attached patch atomic-pgr

Re: [PATCH] Atomic pgrename on Windows

On Tue, Nov 28, 2017 at 2:47 AM, Michael Paquier wrote: > On Mon, Nov 27, 2017 at 3:28 PM, Alexander Korotkov > wrote: > > Attached patch atomic-pgrename-windows-1.patch fixes this problem. It > > appears to be possible to atomically replace file on Windows – > ReplaceFile() > > does that. Rep

Re: [PATCH] Atomic pgrename on Windows

Greetings Alexander, all, * Alexander Korotkov (a.korot...@postgrespro.ru) wrote: > Attached patch atomic-pgrename-windows-1.patch fixes this problem. It > appears to be possible to atomically replace file on Windows – > ReplaceFile() does that. ReplaceFiles() requires target file to exist, > th

Re: [PATCH] Atomic pgrename on Windows

On 2017-11-29 10:13:32 +0800, Craig Ringer wrote: > On 29 November 2017 at 00:16, Alexander Korotkov > wrote: > > > > > For now, ReplaceFile() function looks like best choice for renaming > > statfiles. But it doesn't look good for critical datafiles whose are also > > renamed using pgrename, be

Re: [PATCH] Atomic pgrename on Windows

On 29 November 2017 at 00:16, Alexander Korotkov wrote: > > For now, ReplaceFile() function looks like best choice for renaming > statfiles. But it doesn't look good for critical datafiles whose are also > renamed using pgrename, because system can crash between rename of > destination file and

Re: [PATCH] Atomic pgrename on Windows

On Tue, Nov 28, 2017 at 5:02 AM, Craig Ringer wrote: > On 27 November 2017 at 14:28, Alexander Korotkov < > a.korot...@postgrespro.ru> wrote: > >> It's assumed in PostgreSQL codebase that pgrename atomically replaces >> target file with source file even if target file is open and being read by >>

Re: [PATCH] Atomic pgrename on Windows

On Tue, Nov 28, 2017 at 5:52 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Tue, Nov 28, 2017 at 3:59 AM, Andres Freund wrote: > >> On 2017-11-28 09:47:45 +0900, Michael Paquier wrote: >> > On Mon, Nov 27, 2017 at 3:28 PM, Alexander Korotkov >> > wrote: >> > > Attached patch ato

Re: [PATCH] Atomic pgrename on Windows

On Tue, Nov 28, 2017 at 3:59 AM, Andres Freund wrote: > On 2017-11-28 09:47:45 +0900, Michael Paquier wrote: > > On Mon, Nov 27, 2017 at 3:28 PM, Alexander Korotkov > > wrote: > > > Attached patch atomic-pgrename-windows-1.patch fixes this problem. It > > > appears to be possible to atomically

Re: [PATCH] Atomic pgrename on Windows

On 27 November 2017 at 14:28, Alexander Korotkov wrote: > Hi! > > It's assumed in PostgreSQL codebase that pgrename atomically replaces > target file with source file even if target file is open and being read by > another process. And this assumption is true on Linux, but it's false on > Window

Re: [PATCH] Atomic pgrename on Windows

On 2017-11-28 09:47:45 +0900, Michael Paquier wrote: > On Mon, Nov 27, 2017 at 3:28 PM, Alexander Korotkov > wrote: > > Attached patch atomic-pgrename-windows-1.patch fixes this problem. It > > appears to be possible to atomically replace file on Windows – ReplaceFile() > > does that. ReplaceFil

Re: [PATCH] Atomic pgrename on Windows

On Mon, Nov 27, 2017 at 3:28 PM, Alexander Korotkov wrote: > Attached patch atomic-pgrename-windows-1.patch fixes this problem. It > appears to be possible to atomically replace file on Windows – ReplaceFile() > does that. ReplaceFiles() requires target file to exist, this is why we > still need

[PATCH] Atomic pgrename on Windows

Hi! It's assumed in PostgreSQL codebase that pgrename atomically replaces target file with source file even if target file is open and being read by another process. And this assumption is true on Linux, but it's false on Windows. MoveFileEx() triggers an error when target file is open (and acco