From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Atomic pgrename on Windows |
Date: | 2017-11-29 02:24:00 |
Message-ID: | 20171129022400.jupqhik42gznnt2r@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-11-29 10:13:32 +0800, Craig Ringer wrote:
> 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...
Or we can just add some retry logic like we have for opening files...
> 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.
I'd rather remove windows support than go there.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2017-11-29 02:24:07 | Re: [HACKERS] SQL/JSON in PostgreSQL |
Previous Message | Michael Paquier | 2017-11-29 02:21:27 | Re: [HACKERS] Add Roman numeral conversion to to_number |