Re: Slow catchup of 2PC (twophase) transactions on replica in LR

On Tue, Apr 16, 2024 at 4:25 PM Amit Kapila wrote: > > > > > Can you please once consider the idea shared by me at [1] (One naive > idea is that on the publisher .) to solve this problem? > > [1] - > https://www.postgresql.org/message-id/CAA4eK1K1fSkeK%3Dkc26G5cq87vQG4%3D1qs_b%2Bno4%2Bep654Se

Re: improve performance of pg_dump --binary-upgrade

On Thu, Apr 18, 2024 at 02:08:28AM -0400, Corey Huinker wrote: > Bar-napkin math tells me in a worst-case architecture and braindead byte > alignment, we'd burn 64 bytes per struct, so the 100K tables cited would be > about 6.25MB of memory. > > The obvious low-memory alternative would be to make

Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan

Hi Peter There seems to be an assertion failure with this change in HEAD TRAP: failed Assert("leftarg->sk_attno == rightarg->sk_attno"), File: "../../src/backend/access/nbtree/nbtutils.c", Line: 3246, PID: 1434532 It can be reproduced by: create table t(a int); insert into t select 1 from generat

RE: Disallow changing slot's failover option in transaction block

Dear Shveta, Sorry for delay response. I missed your post. > +1. > > Similar to ALTER SUB, CREATE SUB also needs to be fixed. This is > because we call alter_replication_slot in CREATE SUB as well, for the > case when slot_name is provided and create_slot=false. But the tricky > part is we call

Re: Cannot find a working 64-bit integer type on Illumos

On Thu, 18 Apr 2024 at 08:31, Thomas Munro wrote: > On Sat, Mar 23, 2024 at 3:23 PM Tom Lane wrote: >> Thomas Munro writes: >> > . o O ( int64_t, PRIdi64, etc were standardised a quarter of a century ago >> > ) >> >> Yeah. Now that we require C99 it's probably reasonable to assume >> that th

Re: Disallow changing slot's failover option in transaction block

On Thu, Apr 18, 2024 at 11:22 AM Amit Kapila wrote: > > On Tue, Apr 16, 2024 at 5:06 PM shveta malik wrote: > > > > On Tue, Apr 16, 2024 at 1:45 PM Hayato Kuroda (Fujitsu) > > wrote: > > > > > > Dear Hou, > > > > > > > Kuroda-San reported an issue off-list that: > > > > > > > > If user execute A

Re: improve performance of pg_dump --binary-upgrade

> > One downside of this approach is the memory usage. This was more-or-less > > Bar-napkin math tells me in a worst-case architecture and braindead byte alignment, we'd burn 64 bytes per struct, so the 100K tables cited would be about 6.25MB of memory. The obvious low-memory alternative would be

Re: WIP Incremental JSON Parser

On Wed, Apr 10, 2024 at 07:47:38AM -0400, Andrew Dunstan wrote: > Here's v2 of the cleanup patch 4, that fixes some more typos kindly pointed > out to me by Alexander Lakhin. I can see that this has been applied as of 42fa4b660143 with some extra commits. Anyway, I have noticed another thing in t

Re: Disallow changing slot's failover option in transaction block

On Tue, Apr 16, 2024 at 5:06 PM shveta malik wrote: > > On Tue, Apr 16, 2024 at 1:45 PM Hayato Kuroda (Fujitsu) > wrote: > > > > Dear Hou, > > > > > Kuroda-San reported an issue off-list that: > > > > > > If user execute ALTER SUBSCRIPTION SET (failover) command inside a txn > > > block > > > an

Re: WIP Incremental JSON Parser

On Tue, Apr 09, 2024 at 09:26:49AM -0700, Jacob Champion wrote: > On Tue, Apr 9, 2024 at 7:30 AM Andrew Dunstan wrote: >> I think Michael's point was that if we carry the code we should test we >> can run it. The other possibility would be just to remove it. I can see >> arguments for both. > > H

Re: allow changing autovacuum_max_workers without restarting

> Here is a first attempt at a proper patch set based on the discussion thus > far. I've split it up into several small patches for ease of review, which > is probably a bit excessive. If this ever makes it to commit, they could > likely be combined. I looked at the patch set. With the help of DEB

Re: POC: GROUP BY optimization

On 4/12/24 06:44, Tom Lane wrote: * It seems like root->processed_groupClause no longer has much to do with the grouping behavior, which is scary given how much code still believes that it does. I suspect there are bugs lurking there, and 1. Analysing the code, processed_groupClause is used in:

improve performance of pg_dump --binary-upgrade

While examining pg_upgrade on a cluster with many tables (created with the command in [0]), I noticed that a huge amount of pg_dump time goes towards the binary_upgrade_set_pg_class_oids() function. This function executes a rather expensive query for a single row, and this function appears to be c

Re: Speed up clean meson builds by ~25%

Jelte Fennema-Nio writes: > As I expected this problem was indeed fairly easy to address by still > building "backend/parser" before "interfaces". See attached patch. I think we should hold off on this. I found a simpler way to address ecpg's problem than what I sketched upthread. I have a not-

Re: Popcount optimization using AVX512

It was brought to my attention [0] that we probably should be checking for the OSXSAVE bit instead of the XSAVE bit when determining whether there's support for the XGETBV instruction. IIUC that should indicate that both the OS and the processor have XGETBV support (not just the processor). I've a

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

On Wed, Apr 17, 2024 at 10:31:52AM +0200, Alvaro Herrera wrote: > On 2024-Apr-17, Michael Paquier wrote: >> Yeah, that would be easy enough to track but I was wondering about >> adding the relkind instead. Still, one thing that I found confusing >> is the dump generated in this case, as it would m

Re: sql/json remaining issue

On Mon, Apr 15, 2024 at 9:46 PM Amit Langote wrote: > On Sat, Apr 13, 2024 at 11:12 PM jian he wrote: > > On Fri, Apr 12, 2024 at 5:44 PM Amit Langote > > wrote: > > > > > > > elog(ERROR, "unrecognized json wrapper %d", wrapper); > > > > should be > > > > elog(ERROR, "unrecognized json wrapper

Re: Cannot find a working 64-bit integer type on Illumos

On Sat, Mar 23, 2024 at 3:23 PM Tom Lane wrote: > Thomas Munro writes: > > . o O ( int64_t, PRIdi64, etc were standardised a quarter of a century ago ) > > Yeah. Now that we require C99 it's probably reasonable to assume > that those things exist. I wouldn't be in favor of ripping out our > exi

Re: pg_combinebackup fails on file named INCREMENTAL.*

On 4/18/24 00:14, Robert Haas wrote: On Tue, Apr 16, 2024 at 9:25 AM Robert Haas wrote: On Mon, Apr 15, 2024 at 10:12 PM David Steele wrote: Anyway, I think it should be fixed or documented as a caveat since it causes a hard failure on restore. Alright, I'll look into this. Here's a patch

Re: pg_combinebackup does not detect missing files

On 4/18/24 01:03, Robert Haas wrote: On Tue, Apr 16, 2024 at 7:25 PM David Steele wrote: But it will not go out of its way to perform checks that are unrelated to its documented purpose. And I don't think it should, especially if we have another tool that already does that. I'm not averse to

Re: pgsql: meson: Add initial version of meson based build system

Hi, Uh, huh. On 2024-04-17 15:42:28 +0200, Christoph Berg wrote: > Re: Andres Freund > > https://git.postgresql.org/pg/commitdiff/e6927270cd18d535b77cbe79c55c6584351524be > > This commit broke VPATH builds when the original source directory > contains symlinks. I.e. a symlink to the source direc

Re: fix tablespace handling in pg_combinebackup

Hi, On 2024-04-17 16:16:55 -0400, Robert Haas wrote: > In the "Differential code coverage between 16 and HEAD" thread, Andres > pointed out that there wasn't test case coverage for > pg_combinebackup's code to handle files in tablespaces. I looked at > adding that, and as nobody could possibly hav

plenty code is confused about function level static

Hi, We have a fair amount of code that uses non-constant function level static variables for read-only data. Which makes little sense - it prevents the compiler from understanding a) that the data is read only and can thus be put into a segment that's shared between all invocations of the prog

fix tablespace handling in pg_combinebackup

In the "Differential code coverage between 16 and HEAD" thread, Andres pointed out that there wasn't test case coverage for pg_combinebackup's code to handle files in tablespaces. I looked at adding that, and as nobody could possibly have predicted, found a bug. Here's a 2-patch series to (1) enha

Re: Removing GlobalVisTestNonRemovableHorizon

On 2024-04-16 07:32:55 +0900, Michael Paquier wrote: > On Mon, Apr 15, 2024 at 11:57:20AM -0700, Andres Freund wrote: > > GlobalVisTestNonRemovableHorizon()/GlobalVisTestNonRemovableFullHorizon() > > only > > existed for snapshot_too_old - but that was removed in f691f5b80a8. I'm > > inclined to

Re: Removing GlobalVisTestNonRemovableHorizon

Hi, On 2024-04-15 15:13:51 -0400, Robert Haas wrote: > It would of course have been nice to have done this sooner, but I don't > think waiting for next release cycle will make anything better. I don't really know how it could have been discovered sooner. We don't have any infrastructure for findi

Re: Solaris tar issues, or other reason why margay fails 010_pg_basebackup?

Thomas Munro writes: > This test suite is passing on pollock because it doesn't have IO::Pty > installed. Could you try uninstalling that perl package for now, so > we can see what breaks next? If that's inconvenient for some reason, you could also skip the tab-completion test by setting SKIP_RE

Re: documentation structure

Andres Freund writes: > Hi, > > On 2024-04-17 12:07:24 +0100, Dagfinn Ilmari Mannsåker wrote: >> Andres Freund writes: >> > I think the manual work for writing signatures in sgml is not >> > insignificant, >> > nor is the volume of sgml for them. Manually maintaining the signatures >> > makes

Idea Feedback: psql \h misses -> Offers Links?

Hackers, I often use the ctrl-click on the link after getting help in psql. A great feature. Challenge, when there is no help, you don't get any link. My thought process is to add a default response that would take them to https://www.postgresql.org/search/?u=%2Fdocs%2F16%2F&q={TOKEN}

Re: pg17 issues with not-null contraints

On 2024-Apr-16, Justin Pryzby wrote: > Yes, this fixes the issue I reported. Excellent, thanks for confirming. > BTW, that seems to be the same issue Andrew reported in January. > https://www.postgresql.org/message-id/CAJnzarwkfRu76_yi3dqVF_WL-MpvT54zMwAxFwJceXdHB76bOA%40mail.gmail.com That's r

Re: Solaris tar issues, or other reason why margay fails 010_pg_basebackup?

On Thu, Apr 18, 2024 at 1:40 AM Marcel Hofstetter wrote: > Using gnu tar helps to make pg_basebackup work. Thanks! I guess that'll remain a mystery. > It fails now at a later step. Oh, this rings a bell: [14:54:58] t/010_tab_completion.pl .. Dubious, test returned 29 (wstat 7424, 0x1d00) We

Re: Stack overflow issue

Hi, On 2024-04-17 14:39:14 +0300, Alexander Korotkov wrote: > On Wed, Apr 17, 2024 at 2:37 PM Alexander Korotkov > wrote: > > I've invested more time into polishing this. I'm intended to push > > this. Could you, please, take a look before? > > Just after sending this I spotted a typo s/until

Re: documentation structure

Hi, On 2024-04-17 12:07:24 +0100, Dagfinn Ilmari Mannsåker wrote: > Andres Freund writes: > > I think the manual work for writing signatures in sgml is not insignificant, > > nor is the volume of sgml for them. Manually maintaining the signatures > > makes > > it impractical to significantly imp

Re: documentation structure

Hi, On 2024-04-17 02:46:53 -0400, Corey Huinker wrote: > > > This sounds to me like it would be a painful exercise with not a > > > lot of benefit in the end. > > > > Maybe we could _verify_ the contents of func.sgml against pg_proc. > > > > All of the functions redefined in catalog/system_functi

Re: documentation structure

> > And it's very inconsistent. For example, some functions use > tags for optional parameters, others use square brackets, and some use > VARIADIC to indicate variadic parameters, others use > ellipses (sometimes in tags or brackets). Having just written a couple of those functions, I wasn't

Re: Statistics Import and Export

On Thu, Apr 11, 2024 at 03:54:07PM -0400, Corey Huinker wrote: > At the request of a few people, attached is an attempt to move stats to > DATA/POST-DATA, and the TAP test failure that results from that. > > The relevant errors are confusing, in that they all concern GRANT/REVOKE, > and the fact t

Re: Parallel CREATE INDEX for BRIN indexes

On 4/15/24 20:35, Tomas Vondra wrote: > ... > > Attached is the cleanup I thought about doing earlier in this patch [1] > to make the code more like btree. The diff might make it seem like a big > change, but it really just moves the merge code into a separate function > and makes it use using the

Re: ecpg_config.h symbol missing with meson

Peter Eisentraut writes: > I checked the generated ecpg_config.h with make and meson, and the meson > one is missing > #define HAVE_LONG_LONG_INT 1 > This is obviously quite uninteresting, since that is required by C99. > But it would be more satisfactory if we didn't have discrepancies like

Re: [PATCH] Improve amcheck to also check UNIQUE constraint in btree index.

I did notice (I meant to point out) that I have concerns about this > part of the new uniqueness check code: > " > if (P_IGNORE(topaque) || !P_ISLEAF(topaque)) > break; > " My concern here is with the !P_ISLEAF(topaque) test -- it shouldn't be > required I agree. But I didn't see the need to

Re: pg_combinebackup does not detect missing files

On Tue, Apr 16, 2024 at 7:25 PM David Steele wrote: > Except that we are running pg_combinebackup on the incremental, which > the user might reasonably expect to check backup integrity. It actually > does a bunch of integrity checks -- but not this one. I think it's a bad idea to duplicate all of

Re: Speed up clean meson builds by ~25%

On Wed, 17 Apr 2024 at 16:00, Tom Lane wrote: > Break gram.y (say, misspell some token in a production) and > see what happens. The behavior's likely to be timing sensitive > though. Thanks for clarifying. It took me a little while to break gram.y in such a way that I was able to consistently re

ecpg_config.h symbol missing with meson

I checked the generated ecpg_config.h with make and meson, and the meson one is missing #define HAVE_LONG_LONG_INT 1 This is obviously quite uninteresting, since that is required by C99. But it would be more satisfactory if we didn't have discrepancies like that. Note that we also kept ENABL

Re: Parallel CREATE INDEX for BRIN indexes

On 4/16/24 22:33, Tomas Vondra wrote: > On 4/15/24 20:35, Tomas Vondra wrote: >> On 4/15/24 10:18, Tomas Vondra wrote: > > ... > > That is, no parallel index builds on temporary tables. Which means the > test is not actually testing anything :-( Much more stable, but not very > useful for finding

Re: pg_combinebackup fails on file named INCREMENTAL.*

On Tue, Apr 16, 2024 at 9:25 AM Robert Haas wrote: > On Mon, Apr 15, 2024 at 10:12 PM David Steele wrote: > > Anyway, I think it should be fixed or documented as a caveat since it > > causes a hard failure on restore. > > Alright, I'll look into this. Here's a patch. -- Robert Haas EDB: http:/

Re: Speed up clean meson builds by ~25%

Jelte Fennema-Nio writes: > How can I test if this actually happens? Because it sounds like if > that indeed happens it should be fixable fairly easily. Break gram.y (say, misspell some token in a production) and see what happens. The behavior's likely to be timing sensitive though.

Re: pgsql: meson: Add initial version of meson based build system

Re: Andres Freund > https://git.postgresql.org/pg/commitdiff/e6927270cd18d535b77cbe79c55c6584351524be This commit broke VPATH builds when the original source directory contains symlinks. The $PWD is /home/myon/postgresql/pg/master, but the actual directory is /home/myon/projects/postgresql/pg/pos

Re: Solaris tar issues, or other reason why margay fails 010_pg_basebackup?

Hi Thomas Using gnu tar helps to make pg_basebackup work. It fails now at a later step. Best regards, Marcel Am 17.04.2024 um 10:52 schrieb Thomas Munro: On Wed, Apr 17, 2024 at 7:17 PM Marcel Hofstetter wrote: Is there a way to configure which tar to use? gnu tar would be available. -ba

Re: some LLVM function checks missing in meson

On 13.04.24 10:25, Heikki Linnakangas wrote: Something like the below would appear to fix that: diff --git a/meson.build b/meson.build index 43fad5323c0..cdfd31377d1 100644 --- a/meson.build +++ b/meson.build @@ -2301,6 +2301,14 @@ decl_checks += [ ['pwritev', 'sys/uio.h'],    ] +# Check p

Re: CREATE TABLE creates a composite type corresponding to the table row, which is and is not there

On 29.03.24 02:42, David G. Johnston wrote: We do use the term "stand-alone composite" in create type so I'm inclined to use it instead of "composite created with CREATE TYPE"; especially in the error messages; I'm a bit more willing to add the cross-reference to create type in the user docs.

Re: Speed up clean meson builds by ~25%

On Wed, 17 Apr 2024 at 13:41, Peter Eisentraut wrote: > > On 10.04.24 17:33, Tom Lane wrote: > > The immediate question then is do we want to take Jelte's patch > > as a way to ameliorate the pain meanwhile. I'm kind of down on > > it, because AFAICS what would happen if you break the core > > gr

Re: Building with meson on NixOS/nixpkgs

Peter Eisentraut: On 29.03.24 19:47, walt...@technowledgy.de wrote: > -    uuid = dependency('ossp-uuid', required: true) > +    # upstream is called "uuid", but many distros change this to "ossp-uuid" > +    uuid = dependency('ossp-uuid', 'uuid', required: true) How would this behave if yo

Re: Building with meson on NixOS/nixpkgs

On 29.03.24 19:47, walt...@technowledgy.de wrote: > -uuid = dependency('ossp-uuid', required: true) > +# upstream is called "uuid", but many distros change this to "ossp-uuid" > +uuid = dependency('ossp-uuid', 'uuid', required: true) How would this behave if you have only uuid.pc fr

Re: Speed up clean meson builds by ~25%

On 10.04.24 17:33, Tom Lane wrote: The immediate question then is do we want to take Jelte's patch as a way to ameliorate the pain meanwhile. I'm kind of down on it, because AFAICS what would happen if you break the core grammar is that (most likely) the failure would be reported against ecpg fi

Re: Stack overflow issue

On Wed, Apr 17, 2024 at 2:37 PM Alexander Korotkov wrote: > On Tue, Apr 16, 2024 at 7:42 PM Alexander Korotkov > wrote: > > On Tue, Apr 16, 2024 at 6:35 PM Andres Freund wrote: > > > On 2024-04-16 15:45:42 +0300, Alexander Korotkov wrote: > > > > On Tue, Apr 16, 2024 at 1:48 AM Andres Freund

Re: Stack overflow issue

On Tue, Apr 16, 2024 at 7:42 PM Alexander Korotkov wrote: > > On Tue, Apr 16, 2024 at 6:35 PM Andres Freund wrote: > > On 2024-04-16 15:45:42 +0300, Alexander Korotkov wrote: > > > On Tue, Apr 16, 2024 at 1:48 AM Andres Freund wrote: > > > > On 2024-03-06 14:17:23 +0200, Alexander Korotkov wrote

Re: documentation structure

Andres Freund writes: > Definitely shouldn't be the same in all cases, but I think there's a decent > number of cases where they can be the same. The differences between the two is > often minimal today. > > Entirely randomly chosen example: > > { oid => '2825', > descr => 'slope of the least-s

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

BTW if nothing else, this thread led me to discover a 18-month-old typo in the Spanish translation of pg_dump: -msgstr " --no-tablespaces no volcar métodos de acceso de tablas\n" +msgstr " --no-table-access-method no volcar métodos de acceso de tablas\n" Oops. -- Álvaro Herrer

Re: SQL function which allows to distinguish a server being in point in time recovery mode and an ordinary replica

On 2024-Apr-16, Michael Paquier wrote: there are already too many of them. Perhaps we should begin tracking all that as a set of bitmasks, then plug in the tracked state in shmem for consumption in some SQL function. Yes, it sounds reasonable. Let me implement some initial draft and come back

Re: some LLVM function checks missing in meson

On 13.04.24 10:25, Heikki Linnakangas wrote: There's also this in llvmjit.c:     if (llvm_opt3_orc)     { #if defined(HAVE_DECL_LLVMORCREGISTERPERF) && HAVE_DECL_LLVMORCREGISTERPERF     if (jit_profiling_support)     LLVMOrcUnregisterPerf(llvm_opt3_orc); #endif    

Re: Solaris tar issues, or other reason why margay fails 010_pg_basebackup?

On Wed, Apr 17, 2024 at 7:17 PM Marcel Hofstetter wrote: > 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 Cool. I guess you could fix the test either by s

Re: hash_destroy on the hash table allocated with TopMemoryContext

On Wed, Apr 17, 2024 at 1:04 PM Sharique Muhammed wrote: > Hi, > > I was looking for a pattern to destroy a hashtable (dynahash).allocated > in TopMemoryContext > I found one pattern : create_seq_hashtable uses TopMemoryContext > memory context to create hash table. It calls hash_destroy in > R

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

On 2024-Apr-17, Michael Paquier wrote: > Yeah, that would be easy enough to track but I was wondering about > adding the relkind instead. Still, one thing that I found confusing > is the dump generated in this case, as it would mix the SET and the > ALTER TABLE commands so one reading the dumps m

Re: Typo about the SetDatatabaseHasLoginEventTriggers?

On Wed, 17 Apr 2024 at 14:10, Michael Paquier wrote: > On Tue, Apr 16, 2024 at 03:31:49PM +0900, Michael Paquier wrote: >> Indeed, thanks! Will fix and double-check the surroundings. > > And fixed this one. Thanks for the pushing! -- Regards, Japin Li

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

On Wed, Apr 17, 2024 at 09:50:02AM +0200, Alvaro Herrera wrote: > I think it's easy enough to add a "bool ispartitioned" to TableInfo and > use an ALTER TABLE or rely on the GUC depending on that -- seems easy > enough. Yeah, that would be easy enough to track but I was wondering about adding the

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

On 2024-Apr-17, Alvaro Herrera wrote: > Hmm, cannot we simply add a USING clause to the CREATE TABLE command for > partitioned tables? That would override the > default_table_access_method, so it should give the correct result, no? Ah, upthread you noted that pg_restore-time --no-table-access-me

Re: ALTER TABLE SET ACCESS METHOD on partitioned tables

On 2024-Apr-17, Michael Paquier wrote: > 2) We could limit these extra ALTER TABLE commands to be generated for > partitioned tables. This is kind of confusing as resulting dumps > would mix SET commands for default_table_access_method that would > affect tables with physical storage, while parti

hash_destroy on the hash table allocated with TopMemoryContext

Hi, I was looking for a pattern to destroy a hashtable (dynahash).allocated in TopMemoryContext I found one pattern : create_seq_hashtable uses TopMemoryContext memory context to create hash table. It calls hash_destroy in ResetSequenceCaches. hash_destroy will destroy the memory context(TopMemo

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

On Wed, Apr 17, 2024 at 4:28 PM torikoshia wrote: > > On 2024-04-16 13:16, Masahiko Sawada wrote: > > On Tue, Apr 2, 2024 at 7:34 PM torikoshia > > wrote: > >> > >> On 2024-04-01 11:31, Masahiko Sawada wrote: > >> > On Fri, Mar 29, 2024 at 11:54 AM torikoshia > >> > wrote: > >> >> > >> >> On 202

Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)

On 2024-04-16 13:16, Masahiko Sawada wrote: On Tue, Apr 2, 2024 at 7:34 PM torikoshia wrote: On 2024-04-01 11:31, Masahiko Sawada wrote: > On Fri, Mar 29, 2024 at 11:54 AM torikoshia > wrote: >> >> On 2024-03-28 21:54, Masahiko Sawada wrote: >> > On Thu, Mar 28, 2024 at 9:38 PM torikoshia >>

Re: Solaris tar issues, or other reason why margay fails 010_pg_basebackup?

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.202