From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Atomic pgrename on Windows |
Date: | 2017-11-29 02:13:32 |
Message-ID: | CAMsr+YF7Gm9P-bRTFJ7Kz0KQnCB1WVR7FvK3sSFDNdLuaXhGyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 29 November 2017 at 00:16, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
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 rename of source file. Thus, MoveFileEx() seems still
> best solution for critical datafiles where safety is more important than
> concurrency. After reading provided links, I'm very suspicious about its
> safety too. But it's seems like best available solution and it have
> already passed some test of time...
>
Yeah.
Or alternately, we might need to extend WAL to include any temp file names,
etc, needed to allow us to recover from an interrupted operation during
redo. Frankly that may be the safest option; on Windows presume that there
is no atomic rename we can trust for critical files, and do it in multiple
steps.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-11-29 02:14:05 | Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering |
Previous Message | Michael Paquier | 2017-11-29 02:09:00 | Re: [HACKERS] Causal reads take II |