Re: pg_basebackup check vs Windows file path limits

Поиск
Список
Период
Сортировка
От Alexander Lakhin
Тема Re: pg_basebackup check vs Windows file path limits
Дата
Msg-id 6aa7c5a0-a4c8-dd2c-3a99-946eb7f23155@gmail.com
обсуждение исходный текст
Ответ на Re: pg_basebackup check vs Windows file path limits  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: pg_basebackup check vs Windows file path limits  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
11.11.2023 18:18, Andrew Dunstan wrote:

Hmm, maybe we should be using File::Copy::move() instead of rename(). The docco for that says:

        If possible, move() will simply rename the file. Otherwise, it
        copies the file to the new location and deletes the original. If an
        error occurs during this copy-and-delete process, you may be left
        with a (possibly partial) copy of the file under the destination
        name.

Unfortunately, I've stumbled upon inability of File::Copy::move()
to move directories across filesystems, exactly as described here:
https://stackoverflow.com/questions/17628039/filecopy-move-directories-accross-drives-in-windows-not-working

(I'm sorry for not looking above rename() where this stated explicitly:
# On Windows use the short location to avoid path length issues.
# Elsewhere use $tempdir to avoid file system boundary issues with moving.
So this issue affects Windows only.)

Best regards,
Alexander

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_basebackup check vs Windows file path limits
Следующее
От: Vladimir Churyukin
Дата:
Сообщение: Re: Making auto_explain more useful / convenient