Re: pg_tablespace_location() failure with allow_in_place_tablespaces
От | Kyotaro Horiguchi |
---|---|
Тема | Re: pg_tablespace_location() failure with allow_in_place_tablespaces |
Дата | |
Msg-id | 20220308.120103.515204097583311458.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: pg_tablespace_location() failure with allow_in_place_tablespaces (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pg_tablespace_location() failure with allow_in_place_tablespaces
|
Список | pgsql-hackers |
At Tue, 8 Mar 2022 10:28:46 +0900, Michael Paquier <michael@paquier.xyz> wrote in > On Tue, Mar 08, 2022 at 10:06:50AM +0900, Kyotaro Horiguchi wrote: > > At Tue, 8 Mar 2022 10:39:06 +1300, Thomas Munro <thomas.munro@gmail.com> wrote in > >> Thanks, you're right. Test on a Win10 VM. Here's a new version. > > Looks fine to me. > > > FYI, on Windows11, pg_basebackup didn't work correctly without the > > patch. So this looks like fixing an undiscovered bug as well. > > Well, that's not really a long-time bug but just a side effect of > in-place tablespaces because we don't use them in many test cases > yet, is it? No, we don't. So just FYI. > >> pg_basebackup -D copy > > WARNING: could not read symbolic link "pg_tblspc/16384": Invalid argument > > pg_basebackup: error: tar member has empty name > > > > 1 File(s) 0 bytes > > 3 Dir(s) 171,920,613,376 bytes free > > That's a lot of free space. The laptop has a 512GB storage, so 160GB is pretty normal, maybe. 129GB of the storage is used by some VMs.. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: