Re: Solaris tar issues, or other reason why margay fails 010_pg_basebackup?
От | Marcel Hofstetter |
---|---|
Тема | Re: Solaris tar issues, or other reason why margay fails 010_pg_basebackup? |
Дата | |
Msg-id | 7fa9bd8a-fdd0-42af-b6b1-b3410a1aa293@jomasoft.ch обсуждение исходный текст |
Ответ на | Solaris tar issues, or other reason why margay fails 010_pg_basebackup? (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Solaris tar issues, or other reason why margay fails 010_pg_basebackup?
|
Список | pgsql-hackers |
Hi Is there a way to configure which tar to use? gnu tar would be available. -bash-5.1$ ls -l /usr/gnu/bin/tar -r-xr-xr-x 1 root bin 1226248 Jul 1 2022 /usr/gnu/bin/tar Which tar file is used? I could try to untar manually to see what happens. Best regards, Marcel Am 17.04.2024 um 06:21 schrieb Thomas Munro: > Hi, > > I noticed that margay (Solaris) has started running more of the tests > lately, but is failing in pg_basebaseup/010_pg_basebackup. It runs > successfully on wrasse (in older branches, Solaris 11.3 is desupported > in 17/master), and also on pollock (illumos, forked from common > ancestor Solaris 10 while it was open source). > > Hmm, wrasse is using "/opt/csw/bin/gtar xf ..." and pollock is using > "/usr/gnu/bin/tar xf ...", while margay is using "/usr/bin/tar xf > ...". The tar command is indicating success (it's run by > system_or_bail and it's not bailing), but the replica doesn't want to > come up: > > pg_ctl: directory > "/home/marcel/build-farm-15/buildroot/HEAD/pgsql.build/src/bin/pg_basebackup/tmp_check/t_010_pg_basebackup_replica_data/pgdata" > is not a database cluster directory" > > So one idea would be that our tar format is incompatible with Sun tar > in some way that corrupts the output, or there is some still > difference in the nesting of the directory structure it creates, or > something like that. I wonder if this is already common knowledge in > the repressed memories of this list, but I couldn't find anything > specific. I'd be curious to know why exactly, if so (in terms of > POSIX conformance etc, who is doing something wrong).
В списке pgsql-hackers по дате отправления: