Re: standby recovery fails (tablespace related) (tentative patch and discussion)
От | Kyotaro Horiguchi |
---|---|
Тема | Re: standby recovery fails (tablespace related) (tentative patch and discussion) |
Дата | |
Msg-id | 20211110.171411.1604652159337106356.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: standby recovery fails (tablespace related) (tentative patch and discussion) (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: standby recovery fails (tablespace related) (tentative patch and discussion)
|
Список | pgsql-hackers |
At Tue, 09 Nov 2021 17:05:49 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > At Tue, 9 Nov 2021 12:51:15 +0900, Michael Paquier <michael@paquier.xyz> wrote in > > Look at Utils.pm where we have dir_symlink, then. symlink() does not > > work on WIN32, so we have a wrapper that uses junction points. FWIW, > > I don't like much the behavior you are enforcing in init_from_backup > > when coldly copying a source path, but I have not looked enough at the > > patch set to have a strong opinion about this part, either. > > Thanks for the info. If we can handle symlink on Windows, we don't > need to have a cold copy. I bumped into the good-old 100-byte limit of the (v7?) tar format on which pg_basebackup is depending. It is unlikely in the real world but I think it is quite common in developping environment. The tablespace directory path in my dev environment was 110 chacters-long. As small as 10 bytes but it's quite annoying to chip off that number of bytes from the path.. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: